Cloud–Edge Collaborative Energy Management System: Theory and Practical Experience

Abstract

Rapid growth in renewable generation and electricity-market participation is increasing the number and autonomy of grid-connected resources, challenging conventional centralized energy management systems (EMSs). This paper proposes a cloud–edge collaborative EMS comprising a cloud brain, heterogeneous edge nodes, and a cloud–edge collaboration platform (CCP). The cloud retains wide-area security, market clearing, reserve coordination, and risk-limited dispatch, whereas each edge retains private device models and fast local control. A time-coupled flexibility envelope exposes only aggregate exchange-power, energy, ramp, and reserve limits. A delay-adaptive contraction maps communication latency into a conservative feasible region. Consensus ADMM coordinates the cloud and edge problems, with convergence and complexity discussed. The CCP specifies the data model, messaging protocol, preprocessing, command validation, and failure handling. An illustrative modified IEEE 118-bus benchmark compares centralized, edge-only, basic cloud–edge, and proposed schemes. Under a combined photovoltaic drop and load increase, the proposed method lowers operating cost by 11.1%, curtailment by 52.9%, and peak absolute area control error by 58.1% relative to a deterministic centralized EMS while avoiding load shedding. A 200-edge software emulation reports 4.76 s parallel solver time under the reference configuration. The synthetic study indicates improved coordination, privacy, and delay-aware feasibility.

1. Introduction

Power-system operation is undergoing three simultaneous changes. First, a growing number of virtual power plants, distributed renewable generators, electric vehicles, energy-storage systems, smart buildings, and other flexible resources are participating in system operation and electricity markets [1]. These entities are geographically dispersed, differ substantially in physical characteristics and data formats, and often retain independent economic objectives. Second, system operators must manage both continuous uncertainty, such as wind and photovoltaic forecast errors, and low-frequency, high-impact events, such as extreme weather and communication failures [2,3]. Third, electricity-market reform is shifting operation from primarily heuristic schedules toward optimization-based market clearing and coordinated real-time control.

These changes impose six requirements on the next generation of EMSs. The EMS should: (1) integrate a large and dynamically varying number of loosely coupled market entities; (2) preserve wide-area network security and social-welfare optimization; (3) respect the autonomy and data-privacy requirements of market participants; (4) coordinate global dispatch with rapid local control; (5) use scalable computation and data-driven tools to manage uncertainty [4]; and (6) remain observable, controllable, and secure when connected to public communication networks.

Existing operating strategies can be broadly classified as decentralized and distributed. In decentralized operation, multiple controllers cooperate without a permanent central coordinator [5,6]. In distributed operation, a coordinator decomposes a global problem and exchanges limited variables with local controllers [7,8,9]. Cloud and edge computing provide a practical infrastructure for implementing distributed operation. Existing cloud–edge studies have addressed distribution-network connectivity verification [10], residential energy management [11], microgrid plug-and-play and topology identification [12], cloud–edge load-frequency control [13], and economic dispatch of active distribution networks with multiple microgrids [14]. More recent work has also investigated edge–cloud integration of distributed energy storage [15]. These studies demonstrate the potential of cloud–edge computing, but they generally focus on a particular application rather than an integrated EMS that jointly defines the operation architecture, network-constrained optimization, device-level autonomy, data model, communication process, security mechanism, and transition path from a legacy dispatch center.

Traditional EMSs were designed to monitor and control a finite set of power plants and substations through private communication networks and standardized data models [16,17]. Directly extending this architecture to device-level management of numerous new market entities creates three problems. First, sending all device measurements and constraints to the dispatch center causes excessive communication and computation. Second, participants may be unwilling or unable to disclose private device data. Third, a fully centralized controller reacts slowly to local disturbances and becomes vulnerable to communication failure. Conversely, a purely decentralized architecture cannot reliably enforce wide-area power balance, transmission limits, reserve requirements, and other system-level constraints. A cloud–edge EMS should therefore preserve the dispatch center as the system-security coordinator while delegating private and fast device-level decisions to edge nodes.

The objective of the proposed EMS is explicitly defined as follows: minimize the expected operating cost, renewable curtailment, involuntary load shedding, network loss, and tail risk caused by uncertain renewable generation and demand; maintain power balance, line-flow limits, generator operating limits, reserve adequacy, and local device feasibility; and reduce the amount of private data and real-time computation handled by the cloud. To attain these objectives, this paper proposes a cloud–edge collaboration architecture and a corresponding cloud–edge collaboration platform (CCP).

The main contributions are summarized below.

1. Architecture and responsibility boundary. A bilevel cloud–edge architecture is defined in which the cloud retains network security, market clearing, reserve coordination, and global optimization, while edge nodes retain local state estimation, private device models, fast control, and data preprocessing. The legacy regional–provincial–local EMS hierarchy is integrated as a special edge node rather than replaced.

2. Physically instantiated operating model. A risk-limited flexibility-envelope model explicitly represents power balance, network losses, line and generator limits, ramping, reserve, renewable curtailment, load shedding, storage, charging aggregation, and a traditional EMS. The delay-adaptive contraction links communication latency to physical ramping capability so that delayed commands remain within a conservative feasible region.

3. Computable distributed solution. The cloud and edge problems are coordinated through consensus ADMM using only exchange power, prices, flexibility envelopes, reserve, and quality flags. The stopping criteria, convergence conditions, and computational and communication complexity are stated explicitly.

4. Integrated CCP implementation and evaluation. The CCP data model, message fields, protocol, preprocessing, control sequence, latency treatment, and intrinsic-security checks are specified. A multi-scenario synthetic benchmark and prototype-level emulation compare the proposed method with centralized, edge-only, and basic cloud–edge alternatives using economic, operational, communication, scalability, and security metrics.

Table 1 positions the proposed work relative to representative studies. A check mark indicates that the corresponding issue is explicitly modeled or implemented, whereas a partial mark indicates limited or application-specific treatment.

Table 1. Comparison with representative operation and cloud–edge approaches.

Approach	Wide-Area Network Constraints	Edge Autonomy	Private Device Data Retained Locally	Electricity-Market Support	Renewable Uncertainty/Risk	Explicit Communication and Security Implementation	Integrated Legacy EMS
Traditional EMS [16,17]	✓	—	—	Partial	Partial	Private-network security	✓
Decentralized operation [6]	Partial	✓	✓	Partial	Partial	—	—
Distributed economic MPC [8]	✓	✓	Partial	Partial	Partial	—	—
Cloud–edge connectivity verification [10]	—	✓	✓	—	—	Partial	—
Residential cloud–edge EMS [11]	—	✓	✓	Partial	Partial	Partial	—
Microgrid cloud–edge methods [12,13,14,15]	Partial	✓	✓	Partial	Partial	Partial	—
Proposed CEP	✓	✓	✓	✓	✓	✓	✓

The remainder of the paper is organized as follows. Section 2 presents the cloud–edge architecture and the responsibility boundary. Section 3 develops the physical optimization model and the distributed algorithm. Section 4 describes the CCP design and implementation. Section 5 presents the multi-scenario case study and prototype emulation. Section 6 concludes the paper and discusses limitations and future work.

2. Cloud–Edge Collaboration Architecture

2.1. Architecture

The cloud–edge collaboration architecture consists of one cloud brain and multiple edge neurons, as illustrated in Figure 1. The cloud brain is deployed at the dispatch center and is supported by elastic cloud-computing resources. Edge neurons are deployed at market entities, such as virtual power plants, smart buildings, distributed renewable plants, electric-vehicle aggregators, and energy-storage systems. The traditional regional–provincial–local EMS hierarchy is retained and represented as a special edge neuron.

Figure 1. Cloud–edge collaboration architecture.

The architecture contains two coupled flows. The energy flow is determined by network-constrained dispatch in the cloud and by private device-level scheduling at the edges. The data flow is implemented by the CCP and contains forecasts, flexibility envelopes, market bids, exchange-power requests, prices, measurements, acknowledgements, quality flags, and security status. Raw device-level measurements, customer information, internal topology, and proprietary operating constraints remain at the corresponding edge whenever they are not required for system-level security.

The architecture is bilevel in responsibility but iterative in operation. The cloud has priority over constraints that protect the interconnected grid, including power balance, transmission limits, reserve adequacy, and contingency requirements. Edge nodes have autonomy over internal device scheduling, provided that the aggregate exchange power remains within the envelope registered with the cloud. Consequently, the cloud does not directly control every battery cell, charger, building load, or distributed generator. It controls the aggregate interface and verifies that the response is consistent with the declared flexibility.

2.2. Cloud and Edge Responsibilities

Table 2 defines the division of responsibility that is used consistently in the mathematical model, CCP implementation, and case study.

Table 2. Division of responsibility between the cloud brain and edge neurons.

Function	Cloud Brain	Edge Neuron
Network model	Integrated transmission/distribution equivalent, line limits, system topology	Private internal network and device model
Forecasting	System demand, renewable scenarios, reserve requirement	Local load, renewable output, device availability, user requirement
Optimization	Network-constrained market clearing and risk-limited global dispatch	Private device-level cost/profit optimization
Shared variables	Exchange power, reserve contribution, prices, flexibility envelope	Exchange-power response, local reserve, envelope and quality flags
Fast control	AGC/ACE allocation and system-level corrective signals	Millisecond-to-second device control and internal balancing
Data governance	CIM integration, global validation, audit and authorization	Data cleaning, aggregation, anonymization, and local retention
Security	Identity management, multi-live coordination, attack isolation	Command validation, local safety interlock, autonomous fallback

2.3. Operating Time Scales

The operating framework follows the decision and operating stages shown in Figure 2. Day-ahead decisions use updated forecasts and determine the base schedule. Intra-day or real-time optimization updates the schedule at 15 min intervals. AGC and local controllers operate at faster time scales. The proposed formulation uses a set of scheduling periods $\mathcal{T}=\{1,\dots ,T\}$, with $T=96$ for a 15 min operating day, and a set of uncertainty scenarios $\mathcal{S}$.

Figure 2. Decision stages and operating stages of the cloud–edge strategy.

At each scheduling update, an edge node constructs a feasible exchange-power envelope for the remaining horizon and sends it to the cloud. The cloud then solves the network-constrained problem, returns an exchange-power request and a price signal, and iterates with the edges until the exchange-power mismatch satisfies the stopping tolerance. During real-time operation, each edge tracks the accepted schedule using its local controller and updates its envelope when device availability, state of charge, communication quality, or forecast uncertainty changes.

3. Risk-Limited Flexibility-Envelope Operating Strategy

3.1. Sets, Variables, and Sign Convention

Let $\mathcal{B}$, $\mathcal{L}$, $\mathcal{G}$, $\mathcal{R}$, $\mathcal{I}$, $\mathcal{T}$, and $\mathcal{S}$ denote the sets of buses, branches, conventional generators, renewable generators, edge nodes, time periods, and uncertainty scenarios, respectively. The scenario probability is ${\omega }_s$, and $\sum _s{\omega }_s=1$.

The principal cloud variables are conventional generation $p_{gts}$, bus voltage angle ${\theta }_{bts}$, branch active power $f_{lts}$, branch-loss proxy ${\mathcal{l}}_{lts}$, renewable curtailment $p_{rts}^{\mathrm{c}\mathrm{u}\mathrm{r}}$, involuntary load shedding $p_{bts}^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}$, and the requested exchange power $z_{its}^C$ of edge node $i$. The edge response is $z_{its}^E$. A positive $z_{its}$ means that the edge injects active power into the external grid; a negative value means that the edge consumes active power from the grid.

The cloud does not receive all device-level constraints. Edge node $i$ instead communicates a time-coupled flexibility envelope ${\mathcal{F}}_i$, which contains pointwise power limits, cumulative-energy limits, ramping limits, reserve availability, and a data-quality flag. This envelope is a compact outer description of the private feasible set and is updated whenever local conditions change.

Unless otherwise stated, cloud variables are indexed by scenario $s$. The edge equations in Section 3.5 suppress the scenario index for readability and are enforced for each scenario. The vector ${\mathbf{x}}^C$ collects the cloud variables listed above, whereas ${\mathbf{x}}_i^E$ collects the private variables of edge $i$. The subsets ${\mathcal{G}}_b$, ${\mathcal{R}}_b$, and ${\mathcal{I}}_b$ contain the conventional generators, renewable generators, and edge nodes connected to bus $b$. The variables $R_{its}^{\uparrow }$ and $R_{its}^{\downarrow }$ denote upward and downward reserve supplied by edge $i$, and ${\lambda }_{it}$ is the exchange-price/dual signal.

3.2. Cloud EMS Objective

The EMS minimizes expected operating cost and a tail-risk term [18]:

$$\underset{{\mathbf{x}}^C}{\mathrm{m}\mathrm{i}\mathrm{n}}\hspace{0.33em}\sum _{s\in \mathcal{S}}{\omega }_s{C}_s^{\mathrm{o}\mathrm{p}}+\beta \hspace{0.17em}{\mathrm{C}\mathrm{V}\mathrm{a}\mathrm{R}}_{\alpha }\left({\Phi }_s\right)$$

(1)

where $\beta \ge 0$ is the risk-aversion coefficient and The coefficients $a_g$, $b_g$, and $c_g$ define the convex generation cost of unit $g$; $c^{\mathrm{c}\mathrm{u}\mathrm{r}}$, $c^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}$, and $c^{\mathrm{l}\mathrm{o}\mathrm{s}\mathrm{s}}$ are the penalty coefficients for renewable curtailment, involuntary load shedding, and the branch-loss proxy, respectively. The scalar $\beta$ is the risk-aversion weight and $\alpha$ is the CVaR confidence level.

$$\begin{gathered} C_s^{\mathrm{o}\mathrm{p}}=\sum _{t\in \mathcal{T}}\sum _{g\in \mathcal{G}}\left(a_g{p}_{gts}^2+b_g{p}_{gts}+c_g\right) \\ +c^{\mathrm{c}\mathrm{u}\mathrm{r}}\sum _{t\in \mathcal{T}}\sum _{r\in \mathcal{R}}{p}_{rts}^{\mathrm{c}\mathrm{u}\mathrm{r}} \\ +c^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}\sum _{t\in \mathcal{T}}\sum _{b\in \mathcal{B}}{p}_{bts}^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}+c^{\mathrm{l}\mathrm{o}\mathrm{s}\mathrm{s}}\sum _{t\in \mathcal{T}}\sum _{l\in \mathcal{L}}{\mathcal{l}}_{lts} \\ +\sum _{t\in \mathcal{T}}\sum _{i\in \mathcal{I}}{\lambda }_{it}{z}_{its}^C \end{gathered}$$

(2)

The first term is conventional-generation cost. The next three terms penalize renewable curtailment, involuntary load shedding, and network losses. The final term settles the exchange power of edge nodes at price ${\lambda }_{it}$. The scenario loss ${\Phi }_s$ is defined as the sum of emergency costs caused by load shedding, reserve shortage, and line-overload slack. Its conditional value at risk is represented by [19]

$${\mathrm{C}\mathrm{V}\mathrm{a}\mathrm{R}}_{\alpha }\left(\Phi \right)=\underset{\eta ,{\xi }_s}{\mathrm{m}\mathrm{i}\mathrm{n}}\left\{\eta +{\displaystyle \frac{1}{1-\alpha }}\sum _{s\in \mathcal{S}}{\omega }_s{\xi }_s:\hspace{0.33em}{\xi }_s\ge {\Phi }_s-\eta ,\hspace{0.33em}{\xi }_s\ge 0\right\}$$

(3)

Equation (3) assigns additional weight to low-probability, high-impact operating conditions rather than optimizing only the expected cost.

In (3), $\eta$ is the value-at-risk threshold and ${\xi }_s$ is the nonnegative excess loss in scenario $s$. The scenario loss ${\Phi }_s$ is the emergency-cost component used for risk evaluation; it includes load-shedding cost and any heavily penalized reserve-shortage or line-overload violation introduced during feasibility recovery. These recovery violations are zero in the feasible RLF-CCP cases reported in Section 5.

3.3. Cloud Physical Constraints

3.3.1. Nodal Power Balance and Network Flow

For each bus, time period, and scenario, active-power balance is

$$\begin{gathered} \sum _{g\in {\mathcal{G}}_b}{p}_{gts}+\sum _{r\in {\mathcal{R}}_b}\left({\tilde{p}}_{rts}-p_{rts}^{\mathrm{c}\mathrm{u}\mathrm{r}}\right)+\sum _{i\in {\mathcal{I}}_b}{z}_{its}^C+p_{bts}^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}-d_{bts} \\ =\sum _{l\in \mathcal{L}}{A}_{bl}{f}_{lts}+{\displaystyle \frac{1}{2}}\sum _{l\in \mathcal{L}}\left|A_{bl}\right|{\mathcal{l}}_{lts} \end{gathered}$$

(4)

where $A_{bl}$ is the bus–branch incidence matrix, $d_{bts}$ is demand, and ${\tilde{p}}_{rts}$ is available renewable power. A DC power-flow relation and thermal limit are imposed:

$$f_{lts}=B_l\left({\theta }_{o\left(l\right),ts}-{\theta }_{d\left(l\right),ts}\right),\hspace{1em}\hspace{1em}-{\overline{f}}_l\le f_{lts}\le {\overline{f}}_l$$

(5)

To retain a tractable approximation of active-power loss, the following convex envelope is used:

$${\mathcal{l}}_{lts}\ge {\displaystyle \frac{r_l}{V_0^2}}{f}_{lts}^2, {\mathcal{l}}_{lts}\ge 0$$

(6)

The resulting cloud problem is a convex quadratic or second-order cone program when unit commitment is fixed. For day-ahead commitment with binary variables, the same decomposition can be used with mixed-integer local solves, although the global convergence guarantee then becomes heuristic.

3.3.2. Conventional Generation, Ramping, Renewable Curtailment, and Load Shedding

Conventional units satisfy

$${\underset{\_}{p}}_g\le p_{gts}\le {\overline{p}}_g,\hspace{1em}\hspace{1em}-R_g^{\downarrow }\Delta t\le p_{gts}-p_{g,t-1,s}\le R_g^{\uparrow }\Delta t$$

(7)

Renewable curtailment and involuntary load shedding satisfy

$$0\le p_{rts}^{\mathrm{c}\mathrm{u}\mathrm{r}}\le {\tilde{p}}_{rts}, 0\le p_{bts}^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}\le d_{bts}$$

(8)

The value of $c^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}$ is selected substantially larger than the generation and curtailment costs so that load shedding is used only when physical feasibility cannot otherwise be maintained.

3.3.3. Reserve Adequacy

Upward and downward reserve requirements are

$$\sum _{g\in \mathcal{G}}\left({\overline{p}}_g-p_{gts}\right)+\sum _{i\in \mathcal{I}}{R}_{its}^{\uparrow }\ge R_{ts}^{\mathrm{r}\mathrm{e}\mathrm{q},\uparrow }$$

(9)

$$\sum _{g\in \mathcal{G}}\left(p_{gts}-{\underset{\_}{p}}_g\right)+\sum _{i\in \mathcal{I}}{R}_{its}^{\downarrow }\ge R_{ts}^{\mathrm{r}\mathrm{e}\mathrm{q},\downarrow }$$

(10)

The reserve contribution of an edge node is bounded by the current flexibility envelope and therefore cannot exceed the physically deliverable local response.

The remaining network and operating parameters are as follows: $A_{bl}$ is the bus–branch incidence coefficient; $B_l$, $r_l$, and ${\overline{f}}_l$ are branch susceptance, resistance, and thermal limit; $o\left(l\right)$ and $d\left(l\right)$ are the sending and receiving buses; $V_0$ is nominal voltage; ${\underset{\_}{p}}_g$ and ${\overline{p}}_g$ are generator limits; $R_g^{\uparrow }$ and $R_g^{\downarrow }$ are generator ramp rates; $\Delta t$ is the scheduling interval; and $R_{ts}^{\mathrm{r}\mathrm{e}\mathrm{q},\uparrow }$ and $R_{ts}^{\mathrm{r}\mathrm{e}\mathrm{q},\downarrow }$ are the upward and downward reserve requirements.

3.4. Edge Flexibility Envelope and Delay Adaptation

The generic envelope communicated by edge node $i$ is

$${\mathcal{F}}_i=\left\{{\mathbf{z}}_i:{\underset{\_}{z}}_{it}\le z_{it}\le {\overline{z}}_{it},\hspace{0.33em}{\underset{\_}{E}}_{it}\le {\displaystyle \sum _{\tau =1}^t}{z}_{i\tau }\Delta t\le {\overline{E}}_{it},\hspace{0.33em}\left|z_{it}-z_{i,t-1}\right|\le {\overline{R}}_{it}\Delta t\right\}$$

(11)

The pointwise limits represent instantaneous injection or consumption capability. The cumulative-energy bounds capture state-of-charge, charging-energy, fuel, or comfort requirements. The ramp bound captures the fastest safe change of the aggregate interface.

Communication delay reduces the interval in which an edge can respond to a new cloud command. Let ${\tau }_{it}$ denote the measured round-trip delay and ${\kappa }_i$ denote the worst-case change in local net power per unit delay. The cloud uses the delay-adapted envelope

$${\underset{\_}{z}}_{it}^{\tau }={\underset{\_}{z}}_{it}+{\kappa }_i{\tau }_{it}, {\overline{z}}_{it}^{\tau }={\overline{z}}_{it}-{\kappa }_i{\tau }_{it}$$

(12)

Equation (12) is the principal physical innovation of the model. It converts a communication measurement into a conservative power constraint. A command sent through a delayed link is accepted only when it remains inside $\left[{\underset{\_}{z}}_{it}^{\tau },{\overline{z}}_{it}^{\tau }\right]$. Thus, the cloud does not treat latency as an independent information-technology metric; latency directly changes the dispatchable flexibility available to the power-system optimization.

In (11), ${\underset{\_}{z}}_{it}$ and ${\overline{z}}_{it}$ are the pointwise exchange-power bounds, ${\underset{\_}{E}}_{it}$ and ${\overline{E}}_{it}$ are cumulative-energy bounds, and ${\overline{R}}_{it}$ is the aggregate ramp limit. In (12), ${\tau }_{it}$ is the measured round-trip delay and ${\kappa }_i$ is the conservative rate at which local net power may change during the delay. If contraction makes ${\underset{\_}{z}}_{it}^{\tau }$ greater than ${\overline{z}}_{it}^{\tau }$, the edge is treated as temporarily unavailable for new dispatch and remains at its last verified safe operating point.

3.5. Explicit Edge-Node Models

3.5.1. Edge A: Energy-Storage System

The exchange power and state-of-charge dynamics are

$$z_{A,t}^E=p_t^{\mathrm{d}\mathrm{i}\mathrm{s}}-p_t^{\mathrm{c}\mathrm{h}}, e_t=e_{t-1}+{\eta }^{\mathrm{c}\mathrm{h}}{p}_t^{\mathrm{c}\mathrm{h}}\Delta t-{\displaystyle \frac{p_t^{\mathrm{d}\mathrm{i}\mathrm{s}}\Delta t}{{\eta }^{\mathrm{d}\mathrm{i}\mathrm{s}}}}$$

(13)

subject to

$$\underset{\_}{e}\le e_t\le \overline{e}, 0\le p_t^{\mathrm{c}\mathrm{h}}\le {\overline{p}}^{\mathrm{c}\mathrm{h}}, 0\le p_t^{\mathrm{d}\mathrm{i}\mathrm{s}}\le {\overline{p}}^{\mathrm{d}\mathrm{i}\mathrm{s}}, e_T=e_0$$

(14)

The local objective includes electricity-market revenue, charge/discharge loss, and a convex degradation cost. Simultaneous charging and discharging is avoided either by a binary operating-mode variable or, in the continuous formulation, by positive loss and degradation costs.

3.5.2. Edge B: Charger Aggregator

The charger aggregator consumes power; therefore,

$$z_{B,t}^E=-p_t^{\mathrm{E}\mathrm{V}}, 0\le p_t^{\mathrm{E}\mathrm{V}}\le {\overline{p}}_t^{\mathrm{E}\mathrm{V}}, \sum _{t\in \mathcal{T}}{p}_t^{\mathrm{E}\mathrm{V}}\Delta t=E^{\mathrm{r}\mathrm{e}\mathrm{q}}$$

(15)

Arrival and departure windows are represented in ${\overline{p}}_t^{\mathrm{E}\mathrm{V}}$. Optional lower cumulative-energy bounds ensure that vehicles departing before the end of the horizon receive the required energy. The local objective combines charging expenditure, user-delay penalties, and a smoothness term that discourages abrupt aggregate load changes.

3.5.3. Edge C: Traditional EMS

The traditional EMS is represented as an aggregated controllable area:

$$z_{C,t}^E={\sum }_{g\in {\mathcal{G}}_C}{p}_{gt}^C-d_t^C+q_t^C, \left|p_{gt}^C-p_{g,t-1}^C\right|\le R_g^C\Delta t$$

(16)

where $q_t^C$ represents controllable internal demand or reserve response. The internal unit limits, area balance, and local security constraints remain inside the traditional EMS. Only the feasible exchange-power envelope and reserve capability are exposed to the cloud.

For edge A, $p_t^{\mathrm{c}\mathrm{h}}$ and $p_t^{\mathrm{d}\mathrm{i}\mathrm{s}}$ are charging and discharging power, $e_t$ is stored energy, and ${\eta }^{\mathrm{c}\mathrm{h}}$ and ${\eta }^{\mathrm{d}\mathrm{i}\mathrm{s}}$ are efficiencies. For edge B, $p_t^{\mathrm{E}\mathrm{V}}$ is aggregate charging power, ${\overline{p}}_t^{\mathrm{E}\mathrm{V}}$ is the time-varying availability limit, and $E^{\mathrm{r}\mathrm{e}\mathrm{q}}$ is the required charging energy. For edge C, ${\mathcal{G}}_C$ is the internal generator set, $p_{gt}^C$ is internal generation, $d_t^C$ is internal demand, $q_t^C$ is controllable demand or reserve response, and $R_g^C$ is the internal ramp limit.

3.6. Leader–Follower Equilibrium and Consensus Coupling

The cloud acts as the leader for network security and publishes exchange-power requests and prices. Each edge acts as a follower [20] and minimizes its private cost:

$${\mathbf{x}}_i^{E\ast }\left(\mathsf{\lambda },{\mathbf{z}}_i^C\right)\in \mathrm{a}\mathrm{r}\mathrm{g}\underset{{\mathbf{x}}_i^E\in {\mathcal{X}}_i}{\mathrm{m}\mathrm{i}\mathrm{n}}{C}_i\left({\mathbf{x}}_i^E\right)-\sum _t{\lambda }_{it}{z}_{it}^E+{\displaystyle \frac{{\gamma }_i}{2}}\parallel {\mathbf{z}}_i^E-{\mathbf{z}}_i^C{\parallel }_2^2$$

(17)

The cloud and edge decisions are physically consistent when

$$z_{its}^C=z_{its}^E, \forall i,t,s$$

(18)

For convex generation costs, convex edge costs, continuous operating variables, and nonempty closed feasible sets, the price-supported leader–follower equilibrium is equivalent to the primal–dual optimum of the separable welfare problem with coupling constraint (18) [21]. This equivalence permits a computable distributed solution without transferring the internal models of the edge nodes to the cloud.

In (17)–(24), $C_i$ and ${\mathcal{X}}_i$ are the private objective and feasible set of edge $i$; ${\gamma }_i$ is a nonnegative coordination regularization weight; $J_C$ and $J_i$ are the cloud and edge objective terms in the augmented Lagrangian; $\rho$ is the ADMM penalty parameter; $k$ is the iteration index; and ${\epsilon }^{\mathrm{p}\mathrm{r}\mathrm{i}}$ and ${\epsilon }^{\mathrm{d}\mathrm{u}\mathrm{a}\mathrm{l}}$ are the primal and dual stopping tolerances.

3.7. Consensus ADMM Solution

The augmented Lagrangian is

$${\mathcal{L}}_{\rho }=J_C+\sum _{i\in \mathcal{I}}{J}_i+\sum _i{\mathsf{\lambda }}_i^{\mathsf{T}}\left({\mathbf{z}}_i^C-{\mathbf{z}}_i^E\right)+{\displaystyle \frac{\rho }{2}}\sum _i\parallel {\mathbf{z}}_i^C-{\mathbf{z}}_i^E{\parallel }_2^2$$

(19)

At iteration $k$, the Algorithm 1 performs the following steps.

Algorithm 1: Risk-limited cloud–edge consensus optimization

1. Envelope update. Each edge constructs ${\mathcal{F}}_i$, applies the latency correction in (11), and sends ${\underset{\_}{z}}^{\tau }$, ${\overline{z}}^{\tau }$, cumulative-energy bounds, ramp limits, reserve capability, and quality flags to the cloud.

2. Cloud update. The cloud solves $${\mathrm{x}}^{C,k+1}=\mathrm{a}\mathrm{r}\mathrm{g}\underset{{\mathrm{x}}^C\in {\mathcal{X}}^C}{\mathrm{m}\mathrm{i}\mathrm{n}}{\mathcal{L}}_{\rho }\left({\mathrm{x}}^C,{\mathrm{x}}^{E,k},{\mathsf{\lambda }}^k\right)$$ (20)

3. Parallel edge updates. Each edge solves $${\mathrm{x}}_i^{E,k+1}=\mathrm{a}\mathrm{r}\mathrm{g}\underset{{\mathrm{x}}_i^E\in {\mathcal{X}}_i}{\mathrm{m}\mathrm{i}\mathrm{n}}{\mathcal{L}}_{\rho }\left({\mathrm{x}}^{C,k+1},{\mathrm{x}}_i^E,{\mathrm{x}}_{-i}^{E,k},{\mathsf{\lambda }}^k\right), \forall i$$ (21) and returns only the updated exchange-power response, reserve, and status flags.

4. Price/dual update. The cloud updates $${\mathsf{\lambda }}_i^{k+1}={\mathsf{\lambda }}_i^k+{\rho }_k\left({\mathrm{z}}_i^{C,k+1}-{\mathrm{z}}_i^{E,k+1}\right)$$ (22)

5. Stopping test. The primal and dual residuals are $$r^{k+1}={\left(\sum _i\parallel {\mathbf{z}}_i^{C,k+1}-{\mathbf{z}}_i^{E,k+1}{\parallel }_2^2\right)}^{1/2}$$ (23) $$d^{k+1}={\rho }_k{\left(\sum _i\parallel {\mathbf{z}}_i^{E,k+1}-{\mathbf{z}}_i^{E,k}{\parallel }_2^2\right)}^{1/2}$$ (24) The iteration terminates when $r^{k+1}\le {\epsilon }^{\mathrm{pri}}$ and $d^{k+1}\le {\epsilon }^{\mathrm{dual}}$.

The penalty parameter is increased when the primal residual is much larger than the dual residual and decreased in the opposite case. Warm starts from the previous 15 min interval reduce the number of iterations required in real-time operation.

3.7.1. Convergence

When the cloud and edge objectives are closed, proper, and convex, the feasible sets are nonempty, closed, and convex, and when a saddle point of (19) exists, two-block consensus ADMM converges to a primal–dual optimum [7]. In the present implementation, all edge variables are grouped as one parallel block, so the standard two-block result applies. The residuals in (24) converge to zero, and the objective converges to the optimum. Binary commitment variables or nonconvex AC power-flow constraints violate these assumptions; in that case, the algorithm should be interpreted as a decomposition heuristic, and the final solution must be checked by a centralized feasibility-recovery step.

3.7.2. Computational and Communication Complexity

Let $n_C$ be the number of cloud variables and $n_i$ the number of variables of edge $i$. A dense worst-case interior-point estimate is $O\left(n_C^3\right)$ for the cloud problem and $O\left(n_i^3\right)$ for each edge problem. Power-system matrices are sparse, so practical complexity is substantially lower and depends on sparse factorization fill-in. Because the edge problems are solved in parallel, the edge contribution to wall-clock time is approximately $O\left({\mathrm{m}\mathrm{a}\mathrm{x}}_i{n}_i^3\right)$, rather than $O\left(\sum _i{n}_i^3\right)$. Only $O\left(\left|\mathcal{I}\right|\left|\mathcal{T}\right|\right)$ aggregate values are communicated per iteration. The dependence on the number of edge nodes is therefore approximately linear in communication volume and sublinear in parallel solution time until cloud or network resources become saturated. Section 5.6 evaluates this behavior explicitly.

4. Cloud–Edge Collaboration Platform

The CCP implements the architecture in Section 2 and the operating strategy in Section 3. It provides a consistent data model, a secure cloud–edge control loop, and local retention of private device data.

4.1. Functional and Data-Flow Design

The CCP adopts the bilevel structure shown in Figure 3. The cloud hosts market and system applications, elastic computing, data management, and forecasting services; each edge hosts local acquisition, modeling, forecasting, envelope construction, optimization, command validation, and device control.

Figure 3. Functional and data-flow design of CCP.

Three data paths are distinguished: the existing private-network path to legacy plants and substations, the private path between the cloud and the legacy EMS represented as edge C, and the authenticated Internet-facing path to new edge nodes. Only the third path crosses the demilitarized zone and requires the additional security controls described below.

4.2. CCP Implementation Specification

Table 3 summarizes the CCP implementation specification used by the prototype-level emulation, extending the Docker- and CIM-based design [22] into a reproducible message and control interface.

Table 3. CCP implementation specification used in the prototype emulation.

Item	Cloud System	Edge Node
Runtime	Containerized Linux services orchestrated by Kubernetes	Containerized Linux service managed by a lightweight edge agent
Data model	IEC 61970/61968 CIM integrated model and edge-node registry	Local proprietary model mapped to a CIM-compatible interface model
Messaging	MQTT 5.0 over TLS 1.3; persistent session and quality-of-service level 1	MQTT client with mutual certificate authentication
Payload	Protocol Buffers for real-time messages; XML/CIM for model exchange	Same schema; private device data are not uploaded
Main message fields	GID, timestamp, sequence number, exchange power, reserve, envelope, price, quality flag, signature	Measurement, response, envelope, acknowledgement, alarm, local safety state
Time scales	15 min market/dispatch update; 4 s AGC allocation; 1 s monitoring	1 s aggregation; sub-second local device control
Preprocessing	Timestamp alignment, range check, stale-data check, topology consistency, bad-data flag	Unit conversion, missing-value handling, outlier check, aggregation, anonymization
Delay handling	Round-trip delay estimation and envelope contraction using (11)	Timestamped acknowledgement and local fallback when timeout is exceeded
Security	Mutual TLS, role-based authorization, signed commands, audit log, multi-live cloud control	Command whitelist, magnitude/ramp check, signature verification, autonomous isolation

Model exchange is separated from operational exchange. An edge uploads its interface model only during registration or a model change; normal operation transmits only aggregate variables. This separation limits communication and prevents the cloud problem from expanding with the number of internal devices.

4.3. Multisource Data Merging

The multisource data-merging process contains plug-and-play registration, interface-model transformation, and cloud-side integration, as shown in Figure 4.

Figure 4. Multisource data-merging process.

During registration, the edge authenticates with its globally unique identifier (GID) and certificate. A containerized adapter maps local fields, units, and device types to the CCP interface schema. The cloud converts the interface model to a CIM-compatible representation and integrates it only after the edge verifies completeness and the cloud verifies topology and parameter consistency.

Preprocessing is divided between the two levels. The edge performs unit conversion, timestamp alignment, missing-value handling, plausibility checks, and aggregation; the cloud checks sequence numbers, staleness, ranges, rates of change, envelope consistency, and command–response agreement. Invalid or stale envelopes are replaced by conservative fallback capabilities until valid data are restored.

4.4. Cloud–Edge Control Sequence

Figure 5 and Figure 6 summarize the control-security sequence and the coupled data and energy flows. Storage and the traditional EMS are Type 2 nodes that can provide energy, reserve, and AGC services; the charger aggregator is a Type 1 node that participates in energy scheduling but not fast frequency regulation in the present study.

Figure 5. Intrinsic-security process.

Figure 6. Coupled data and energy sequence in the proposed CCP.

At each optimization cycle, an edge forecasts local conditions and constructs its flexibility envelope. The cloud integrates the envelopes into the network-constrained problem and returns exchange-power requests and prices. Each edge verifies the command identity, timestamp, sequence number, magnitude, ramp rate, and local feasibility before solving its private problem. In real time, the cloud allocates ACE within accepted reserve capacities, while local controllers track the assigned aggregate signal without exposing device-level states.

4.5. Intrinsic Security and Failure Handling

The intrinsic-security process in Figure 5 supplements defense-in-depth network protection [23]. Firewalls, unidirectional gateways, a demilitarized zone, mutual authentication, encryption, and role-based access control protect the communication path. Each command also carries an authenticated application identity, timestamp, sequence number, validity interval, and digital signature. The cloud checks authorization and consistency with the accepted schedule, while the edge independently checks the current envelope, power and ramp limits, and safety interlocks. Failed checks cause rejection, logging, and, after repeated abnormal messages, edge isolation and certificate revocation.

The cloud uses a multi-live configuration in which a consensus/lease mechanism designates one active command issuer while other nodes maintain synchronized state. If the active node fails, command authority transfers to a healthy node. If an edge link exceeds its timeout, the edge holds the last safe base point, releases only locally verified droop/AGC capability, and reports an alarm after communication recovers.

5. Synthetic Benchmark Case Study and Prototype Emulation

5.1. Scope, Reference Configuration, and Assumptions

This section reports an internally consistent synthetic benchmark and software-emulation study of the physical model and CCP workflow. No utility field measurements or hardware-in-the-loop results are claimed. The network is based on the IEEE 118-bus case in MATPOWER [24], and the renewable, demand, communication-delay, and attack profiles are synthetic. The values in Table 4, Table 5, Table 6, Table 7 and Table 8 are used for controlled comparison under a fixed parameterization and should not be interpreted as field-performance claims.

Table 4. Normal-operation comparison.

Method	Operating Cost (106 CNY/Day)	Renewable Curtailment (%)	Network Loss (%)	ACE RMSE (MW)	End-to-End Cycle Time (s)	Communication per Interval (MB)
C-EMS	3.82	8.7	1.94	18.6	4.21	182.40
E-only	4.11	11.8	2.46	22.4	0.72	24.60
B-CCP	3.67	6.9	1.78	12.5	1.31	12.80
RLF-CCP	3.48	4.6	1.63	7.8	1.56	8.16

Table 5. Results under high renewable penetration and the combined disturbance.

Method	Operating Cost (106 CNY/Day)	Curtailment (%)	Load Shedding (MWh)	Maximum Line Loading (%)	Peak Absolute ACE (MW)
C-EMS	4.23	10.4	8.2	102.8	31.5
E-only	4.39	12.9	5.7	108.6	39.0
B-CCP	3.98	7.1	1.8	99.4	20.5
RLF-CCP	3.76	4.9	0.0	96.2	13.2

Table 6. Effect of communication delay.

Round-Trip Latency (ms)	B-CCP Tracking Error (%)	RLF-CCP Tracking Error (%)	B-CCP Infeasible Commands	RLF-CCP Infeasible Commands	RLF-CCP Envelope Contraction (%)
50	1.9	1.8	0	0	0.8
250	3.7	2.6	1	0	4.2
500	7.8	4.2	6	0	8.7
1000	15.4	7.1	17	1	17.4

Table 7. Scalability results.

Edge Nodes	ADMM Iterations	Parallel Solution Time (s)	Communication per Iteration (MB)	Peak Cloud Memory (GB)
3	24	0.82	0.34	1.2
10	24	0.94	1.08	1.4
50	26	1.56	5.31	2.5
100	28	2.48	10.55	4.0
200	30	4.76	21.02	6.9

Table 8. Security emulation results.

Security Configuration	Attacks Detected	Malicious Commands Executed	Maximum Unintended Power Deviation (MW)	Mean Isolation Time (s)	Mean Service-Restoration Time (s)	Thermal-Limit Violation
Boundary security only	2/20	18/20	78	241.0	318.0	Yes
Boundary + intrinsic CCP security	20/20	0/20	0	0.42	2.8	No

The benchmark contains 118 buses, 186 branches, and 54 conventional generators. Eight wind plants totaling 1600 MW and twelve photovoltaic plants totaling 1400 MW are placed at geographically dispersed buses. The daily load follows the original bus proportions and varies from 2.85 to 4.35 GW. Twenty wind, photovoltaic, and load scenarios are generated around the day-ahead forecast. The horizon contains 96 intervals of 15 min.

Three physical edge nodes are connected in the base case:

Edge A: energy storage. Rated power 300 MW, energy capacity 1200 MWh, initial/final state of charge 50%, SOC range 10–90%, charging efficiency 0.95, and discharging efficiency 0.94.

Edge B: charger aggregator. Maximum aggregate charging power 240 MW, required daily charging energy 1440 MWh, time-varying vehicle availability, and user-departure energy constraints.

Edge C: traditional EMS. Six aggregated conventional units and controllable loads with 300 MW upward and 260 MW downward response capability.

The cloud uses $\alpha =0.95$, $\beta =0.15$, $c^{\mathrm{c}\mathrm{u}\mathrm{r}}=400$ CNY/MWh, and $c^{\mathrm{s}\mathrm{h}\mathrm{e}\mathrm{d}}=20,000$ CNY/MWh. The ADMM penalty begins at $\rho =10$, and the normalized primal and dual tolerances are ${10}^{-3}$. The operating results use the fixed scenario set described above. Runtime and memory statistics are averaged over ten runs after one warm-up run and are reported for the reference software-emulation environment defined below.

The reference environment is defined as Ubuntu 22.04 LTS on a 32-core AMD EPYC 7543P server with 128 GB RAM, using Python 3.11, Pyomo 6.7, Gurobi 11.0, MATPOWER 8.0 for the base network data, Docker 26, and Kubernetes 1.30. The cloud service is allocated 16 vCPUs and 32 GB RAM, and each edge container is allocated 1 vCPU and 1 GB RAM. The cloud and edge solves run as separate services, with the edge subproblems solved in parallel. The reported timing and memory values are software-emulation results for this reference configuration, not measurements from utility control hardware.

5.2. Compared Methods and Metrics

Four methods are compared.

1. Centralized deterministic EMS (C-EMS). The cloud receives the device-level time series and aggregate constraints required by a centralized solve and optimizes a single forecast. It does not use CVaR, distributed edge optimization, or delay-adapted envelopes.

2. Edge-only control (E-only). Each edge minimizes its local cost independently. The cloud performs a feasibility check but does not co-optimize the schedules; network violations are corrected afterward by conventional redispatch.

3. Basic cloud–edge coordination (B-CCP). The cloud and edges exchange power schedules through consensus ADMM, but the cloud uses expected cost only and does not contract envelopes for communication delay. Delayed infeasible responses require subsequent corrective message exchanges.

4. Proposed risk-limited flexibility-envelope CCP (RLF-CCP). The complete formulation in Section 3 is used.

The principal metrics are daily operating cost, renewable curtailment, involuntary load shedding, network loss, maximum line loading, area-control-error (ACE) root-mean-square and peak values, end-to-end cycle time, communication volume, ADMM iterations, memory use, and security detection/recovery time. The evaluation proceeds from normal operation to a combined renewable-and-load disturbance, followed by dedicated delay, scalability, convergence, and security tests.

5.3. Normal-Operation Comparison

Table 4 reports the normal-operation comparison. RLF-CCP yields the lowest expected operating cost and renewable curtailment. Relative to C-EMS, it reduces cost from 3.82 to 3.48 million CNY (8.9%), curtailment from 8.7% to 4.6% (47.1%), and ACE RMSE from 18.6 to 7.8 MW (58.1%). Storage and charging flexibility are co-optimized with transmission and reserve constraints. E-only has the shortest cycle time but the highest loss and weakest tracking because its local schedules are not coordinated with the network.

RLF-CCP reduces communication per interval from 182.40 to 8.16 MB (95.5%) relative to C-EMS because it exchanges aggregate envelopes and interface values rather than device-level time series and constraints. The 8.16 MB value equals 0.34 MB per iteration over 24 iterations in the three-edge case, consistent with Table 7. B-CCP requires additional corrective exchanges when delayed responses become infeasible. Table 4 reports end-to-end cycle time, whereas Table 7 isolates parallel solver time. The next experiment tests whether the baseline advantages persist under a combined renewable-generation and load disturbance.

5.4. High-Renewable and Combined Disturbance Scenario

A stressed scenario is constructed to activate the mechanisms modeled in Section 3. Renewable generation supplies approximately 50% of daily energy. At 18:00, photovoltaic availability decreases by 230 MW within one hour while demand increases by 260 MW; wind forecast error is superimposed, and two transmission interfaces operate close to their limits. Figure 7 shows the RLF-CCP dispatch. Storage shifts midday photovoltaic surplus to the evening event, the charger aggregator moves part of its energy requirement away from the constrained period, and edge C supplies upward reserve.

Figure 7. RLF-CCP dispatch under the photovoltaic-drop and load-step scenario.

Table 5 compares the four methods. Before corrective redispatch, C-EMS and E-only violate at least one branch limit. C-EMS sheds 8.2 MWh because its deterministic schedule underestimates the combined ramp and reserve requirement; B-CCP reduces load shedding to 1.8 MWh. RLF-CCP limits maximum line loading to 96.2%, eliminates load shedding, and reduces operating cost by 11.1% and curtailment by 52.9% relative to C-EMS.

Figure 8 shows the ACE response around the event. RLF-CCP has the smallest peak and the fastest settling because the cloud allocates network-feasible reserve while edges A and C implement the aggregate response through local controllers. Because this coordination depends on timely envelope and command exchange, the next experiment isolates communication delay.

Figure 8. ACE response to the photovoltaic-drop and load-step event.

5.5. Communication Delay and Latency-Adapted Flexibility

The delay test varies cloud–edge round-trip latency from 50 to 1000 ms. A command is infeasible if it falls outside the true local envelope at execution time. B-CCP uses the envelope available at cloud-computation time, so its tracking error and infeasible-command count increase with latency. RLF-CCP applies (11), sacrificing a limited amount of apparent flexibility to preserve execution feasibility.

At 1000 ms, RLF-CCP reduces tracking error by 53.9% relative to B-CCP. The single infeasible command occurs when a change in charger availability coincides with the maximum delay; the edge safety check rejects it, and the cloud recomputes the schedule. Thus, envelope contraction reduces infeasible requests, while the edge interlock prevents unsafe execution. The next test examines scalability as the number of edge nodes increases.

5.6. Multi-Edge Scalability, Runtime, and Convergence

For the scalability test, the three base edge models are replicated with heterogeneous capacities and time windows to create cases with 3, 10, 50, 100, and 200 edge nodes. Internal device models remain at the edges. Table 7 and Figure 9 show approximately linear communication growth and a parallel solver time increase from 0.82 s for three nodes to 4.76 s for 200 nodes, well below the 15 min dispatch interval.

Figure 9. Parallel solution time and communication volume versus the number of edge nodes.

Figure 10 shows the normalized primal residual for representative system sizes. The 3-, 50-, and 200-node cases reach the 10−3 tolerance in 24, 26, and 30 iterations, respectively. The moderate increase indicates that scalability is governed primarily by message volume and cloud factorization rather than a sharp deterioration in consensus convergence.

Figure 10. ADMM convergence for 3, 50, and 200 edge nodes.

The result supports coordination of hundreds of edge nodes under the stated reference configuration; it does not establish unlimited scalability. Larger systems will require hierarchical aggregation, asynchronous updates, or further decomposition. The final emulation therefore evaluates command-layer security and failure handling.

5.7. Intrinsic-Security Emulation

The security emulation injects 20 falsified exchange-power commands at edge A. Each command changes the requested power by 30% and uses either an invalid application signature or a valid communication session with a command outside the accepted envelope. Table 8 compares conventional network-boundary protection with the proposed intrinsic checks.

Signature verification detects commands from unauthorized applications, and the independent envelope check detects authenticated but physically inconsistent commands. After rejection, edge A maintains its last safe base point and local droop response; the multi-live cloud restores command service without interrupting monitoring. The test covers only the two implemented attack classes and is not a comprehensive cybersecurity certification.

5.8. Discussion

The comparative results show that both levels are necessary. E-only is fast but cannot enforce wide-area network and ACE performance; C-EMS transfers much more data and is less robust to forecast error. The flexibility envelope provides a practical boundary between global scheduling and private local models, and the latency-adapted contraction in (11) improves execution feasibility under delayed communication.

The study remains limited to an illustrative synthetic benchmark and software emulation. It uses DC power flow, a convex loss proxy, fixed commitment, authenticated time synchronization, and bounded delay. The ADMM guarantee applies to the continuous convex formulation, and the security test covers only command forgery and out-of-envelope control. Field data, AC and mixed-integer models, hardware-in-the-loop testing, and broader cyberattack classes remain future work.

6. Conclusions

This paper presents an integrated cloud–edge EMS in which the cloud retains network-constrained dispatch, market clearing, reserve coordination, and system-level security, while edge nodes retain private models, local forecasting, fast control, and safety interlocks. Treating the legacy EMS as a special edge node provides a gradual migration path.

The core method is a risk-limited, time-coupled flexibility envelope whose delay-adaptive contraction maps communication latency into a conservative dispatchable region. Consensus ADMM coordinates the cloud and edge problems using aggregate exchange variables, and the CCP implements the associated data, communication, control, and security processes.

In the illustrative IEEE 118-bus benchmark, RLF-CCP improves cost, curtailment, network loading, ACE, and communication performance relative to the comparison methods; the 200-edge emulation converges in 30 iterations with a 4.76 s parallel solver time under the reference configuration. These results support the internal consistency and comparative potential of the framework, but they do not replace field validation.

Future work will use utility data and hardware-in-the-loop tests, incorporate AC voltage/reactive-power constraints and mixed-integer commitment, develop hierarchical or asynchronous coordination for larger systems, and evaluate coordinated false-data injection, denial-of-service, and compromised-edge attacks.