Cloud Control Systems (CCSs)

• Cloud Control Systems are architectures where cloud computing is integrated with control processes to manage physical plants, distributed infrastructures, and governance functions.
• They encompass diverse applications including cloud-hosted CPSs, predictive control loops, and dynamic cloud infrastructure management across industrial, vehicular, and energy domains.
• Empirical studies highlight tradeoffs in latency, computational overhead, and robustness, guiding the optimization of scheduling, security, and compliance in dynamic network conditions.

Cloud Control Systems (CCSs) denote a heterogeneous class of architectures in which cloud infrastructure becomes part of the control plane of a cyber-physical, computational, or governance process. In control-oriented work, a CCS is a networked cyber-physical system whose controller logic is deployed in a cloud service provider while the plant remains physically separate and exchanges measurements and commands with the cloud over a communication network (Naseri et al., 2021). Other strands use the term for a personal cloud control centre spanning software, data, and resources (Spillner et al., 2012), for dynamic monitoring and management of cloud infrastructures (McGilvary et al., 2013), for a distributed cloud back-end supporting vehicular video analytics (Hammoudi et al., 2014), for standards-based cloud-to-edge control of distributed energy resources (Leniston et al., 5 Jun 2025), and for governance-oriented control planes for compliance or sovereignty (Sonkar, 16 May 2025). A 2025 review characterizes CCSs more generally as the evolution of Networked Control Systems integrated with cloud computing, in which sensors transmit plant data to the cloud, the cloud performs control computation or optimization, and resulting control inputs are returned to actuators (Ali et al., 11 Sep 2025).

1. Conceptual scope and historical development

The published record represented here spans markedly different meanings of control. Early work on $\pi$-Control proposed a user-centric cloud model beyond conventional $<SPI>aaS$, replacing it with $O:=\{S,D,R,\ldots\}$ and the corresponding $<SDR>aaS$ service definition, so that software, data, and resources become first-class objects of cloud control across trust zones $T=0$ and $T>0$ (Spillner et al., 2012). C2MS then treated CCS as monitoring and controlling dynamic groups of physical or virtual servers within cloud infrastructures, while later control-theoretic papers used CCS to denote cloud-hosted CPSs, resilient cloud control loops, and data-driven predictive cloud control platforms (McGilvary et al., 2013).

A recurrent source of ambiguity is therefore terminological rather than methodological. Some CCSs control a physical plant; some control a cloud infrastructure; some control access, compliance, or sovereignty; and some provide an application-specific intelligence layer. This suggests that CCS is best understood as a family of cloud-mediated control planes rather than a single canonical architecture. The review literature reinforces that breadth by organizing CCS research around cloud-based control techniques, security and privacy, and industrial deployment, while also contrasting CCSs with traditional NCSs in terms of centralized cloud storage and processing, scalability, computational power, flexibility, and dependence on cloud-service availability (Ali et al., 11 Sep 2025).

The historical trajectory also shows a gradual broadening of what counts as the “plant.” In classical cloud-hosted CPS formulations, the plant is a physical process such as the quadruple tank process or a ball-and-beam system (Naseri et al., 2021). In infrastructure-oriented formulations, the plant is a hybrid cloud, a distributed cloud network, or a geographically distributed set of data centers whose state is expressed by queues, host utilizations, or VM placements (Pluzhnik et al., 2014). In governance-oriented formulations, the relevant state variables are control mappings, evidence artifacts, privileged access, and recovery authority (Stark et al., 15 Apr 2026).

2. Architectural patterns and control loops

The canonical control-oriented CCS loop places sensing and actuation near the physical process and moves substantial computation to the cloud. In the secure cloud-hosted CPS model, the controller receives sensor data from the plant, computes control inputs according to a predefined control law, and sends actuator commands back over the network, with the controller logic deployed in a cloud service provider (Naseri et al., 2021). The review literature presents the same pipeline in generalized form: sensors acquire plant data, the cloud performs control computation, prediction, optimization, or security processing, and the resulting control input is sent to the actuators (Ali et al., 11 Sep 2025).

Architectures differ mainly in how they compensate for uncertainty introduced by cloud execution and networking. The Resilient Cloud Control System (R-CCS) uses a plant-side client, a predictive cloud controller, local frequency adaptation or rate-switching logic, and a local recovery controller. Its defining idea is that the control system should adapt its behavior to the present Quality of Service of the cloud and the intermediate network, a property the paper terms quality elasticity (Tärneberg et al., 2023). The Data-driven Predictive Cloud Control System (DPCCS) formalizes this separation as a three-layer architecture consisting of a cloud platform layer, an edge layer, and a user layer, with the edge client receiving predictive control sequences, estimating communication delay, and selecting the appropriate element of the sequence for actuation (Gao et al., 2021).

Application-specific CCSs often appear as distributed dataflow architectures rather than abstract feedback loops. In the vehicular Hybrid Vehicular Cloud, the main chain is onboard camera/GPS/Raspberry Pi $\rightarrow$ FTP transfer to RSU $\rightarrow$ SSH distribution from RSU to cloud nodes $\rightarrow$ parallel algorithm execution $\rightarrow$ database/file server storage $<SPI>aaS$0 RESTful API/web visualization (Hammoudi et al., 2014). In residential energy systems, the architecture couples an edge gateway speaking SunSpec Modbus with an Azure cloud layer exposing IEEE 2030.5-compatible telemetry and control, using IoT Hub, Azure Functions, SQL-based storage, device twins, and containerized gateway services (Leniston et al., 5 Jun 2025).

Infrastructure CCSs exhibit the same loop in operational rather than physical terms. The hybrid-cloud application control architecture described in 2014 explicitly joins a SaaS portal, an autonomous automatic control system or framework with optimization modules, and hybrid cloud IaaS (Pluzhnik et al., 2014). C2MS decomposes into Monitoring, Control, and Cloudlet Creator, enabling administrators to define cloudlets, observe group-level and server-level metrics, and execute group actions without restarting Ganglia daemons (McGilvary et al., 2013). In each case, observation, decision, and enforcement are separated, even when the controlled substrate is not a physical plant.

3. Control, optimization, and adaptation methods

Control-theoretic CCS work spans state-space control, MPC, queue-stabilizing network control, and data-driven prediction. For hybrid cloud services, a discrete-time linear model is used,

$<SPI>aaS$1

where $<SPI>aaS$2 is the state vector and $<SPI>aaS$3 is the control vector, so that monitoring feedback can regulate resource allocation, traffic priorities, and request handling under QoS objectives (Pluzhnik et al., 2014). In distributed cloud networking, the plant is the queuing system itself, and Dynamic Cloud Network Control (DCNC) uses online minimization of linear or quadratic metrics derived from an upper bound on the Lyapunov drift-plus-penalty. The resulting algorithms stabilize the queuing system, achieve arbitrarily close to minimum cost with a tradeoff in network delay, and exhibit the familiar $<SPI>aaS$4 cost-gap and $<SPI>aaS$5 backlog tradeoff, with convergence to within $<SPI>aaS$6 of optimum in time $<SPI>aaS$7 (Feng et al., 2017).

Predictive control occupies a central place because cloud deployment amplifies delay variability. The R-CCS uses an MPC-like optimization service that returns a full predicted sequence of future control actions rather than a single action, enabling latency mitigation by open-loop prediction when responses arrive late. Its adaptive layer regulates the request rate on the basis of deadline misses and smoothed loss estimates, quantizing the adapted sampling period and bounding it between $<SPI>aaS$8 and $<SPI>aaS$9 (Tärneberg et al., 2023). This architecture is explicitly designed for interruptions, noisy neighbors, heterogeneous worker nodes, and seamless switching among Kubernetes, OpenStack, and AWS Lambda deployments.

The data-driven line of work removes the need for an explicit plant model and instead constructs prediction from Hankel matrices of measured data. DPCCS represents the predicted future output as

$O:=\{S,D,R,\ldots\}$0

and the unconstrained predictive control sequence as

$O:=\{S,D,R,\ldots\}$1

with cloud-side least-squares identification of $O:=\{S,D,R,\ldots\}$2 and $O:=\{S,D,R,\ldots\}$3 and edge-side delay compensation based on the measured upload, computation, and download delays (Gao et al., 2021). A plausible implication is that cloud resources are used not only for solving large optimization problems but also for continuously refreshing implicit models from streaming data.

At the infrastructure scale, optimization increasingly includes exogenous forecasts. The pervasive cloud controller for geotemporal inputs treats electricity price and temperature time series as forecasted control inputs, evaluates candidate schedules over a forecast window, and uses a two-stage optimization strategy consisting of a genetic algorithm followed by greedy repair (Lučanin et al., 2018). This extends CCS logic from workload-reactive scheduling to forecast-driven receding-horizon control over geographically distributed data centers.

4. Security, privacy, compliance, and sovereignty

Security research treats the cloud not merely as a computational accelerator but as an adversarial boundary inserted directly into the control loop. The secure cloud-hosted CPS model argues that encrypted authenticated communication protects the network but does not protect the controller running in the cloud, since a malicious cloud operator or compromised OS may still access plaintext after decryption, steal keys, or alter controller code and state (Naseri et al., 2021). The proposed response is a TEE-based secure control architecture combining authenticated encryption for plant-cloud communication with an Intel SGX enclave that protects controller logic, runtime state, and cryptographic keys, while remote attestation establishes trust in the controller before execution begins.

Privacy-oriented CCS research adopts a different strategy: rather than relying solely on heavy cryptography, it transforms the control problem itself. For the discrete-time affine plant

$O:=\{S,D,R,\ldots\}$4

the cloud is modeled as an honest-but-curious adversary, and the plant sends a transformed but equivalent optimization problem using control-system isomorphisms and symmetries (Sultangazin et al., 2019). The cloud solves the transformed problem, while the plant decodes the result. Privacy is quantified by the dimension of the uncertainty set induced by the equivalence class, and the computational overhead is described as $O:=\{S,D,R,\ldots\}$5 in handshaking and execution, reducible to $O:=\{S,D,R,\ldots\}$6 with precomputation.

Security concerns become broader in cloud-enabled industrial control. Survey work on ICSs documents how migration to IaaS, cloud SCADA, and cloud-based cyber-physical industrial architectures expands the attack surface to APTs, DDoS, supply-chain compromise, multi-tenant threats, and the loss of control over data security and privacy (Bhamare et al., 2020). The same survey argues that encryption alone is insufficient, motivating ML-based intrusion and anomaly detection, cloud-specific access control, and fog-assisted mitigation; one cited fog-computing framework improved detection rate by about $O:=\{S,D,R,\ldots\}$7 against TCP SYN flooding and forged Modbus command-data exploitation (Bhamare et al., 2020).

A distinct governance literature uses CCS in the sense of a cloud control plane for compliance. Cisco Common Control Framework v4.0 is presented as a unified governance architecture that normalizes ISO 27001, SOC 2, NIST, FedRAMP, EU CRA, DORA, NIS2, HDS, and Saudi ECC into a single internal control library, with the Control Advisory Board acting as the decision-making and conflict-resolution layer for mapping and validation (Sonkar, 16 May 2025). Related sovereignty work then argues that cloud sovereignty cannot be reduced to data residency or infrastructure location alone. “Management sovereignty” is defined as enforceable governance, operational execution, evidence generation, and trust control within the sovereign boundary under steady-state and disruption conditions, operationalized through a three-layer risk-assurance framework spanning governance, operational, and technical controls and anchored by post-quantum-ready TLS and PKI (Stark et al., 15 Apr 2026). A common misconception addressed by this literature is that sovereignty is a property of location; the counterclaim is that sovereignty is an evidence-backed control system.

5. Representative application domains

Vehicular systems provide one of the clearest examples of an application-specific CCS. The 2014 VANET paper treats the CCS as the central back-end element of a hybrid vehicular cloud architecture combining embedded cameras, GPS, IEEE 802.11p communication, RSUs, cloud storage, parallel recognition algorithms, databases, file servers, and web services (Hammoudi et al., 2014). Its example use cases are parking area detection, road meteorology mapping, license-plate extraction for stolen vehicle detection, and face extraction for locating individuals, with a police-monitoring scenario that localizes and labels extracted features on a Google Maps-based application in quasi real time.

Industrial and cyber-physical applications dominate the control-theoretic literature. Secure cloud-hosted control is validated on the quadruple tank process using a dynamic output feedback controller with a Luenberger observer and an optimal LQ controller (Naseri et al., 2021). R-CCS uses a Ball-and-Beam process to demonstrate survival under interruptions, noisy neighbors, and time-varying resource availability (Tärneberg et al., 2023). DPCCS also validates its cloud-edge platform on a ball-beam system, using PID to generate initial data and then switching to data-driven predictive control (Gao et al., 2021). The 2025 review broadens the domain list to smart transportation, smart homes, healthcare, smart cities, and smart grids, emphasizing that CCSs are particularly attractive where decisions are optimization-heavy and data volumes exceed local computational capacity (Ali et al., 11 Sep 2025).

Energy systems illustrate the convergence of protocol interoperability and cloud control. The residential DER architecture links a Raspberry Pi 4 gateway and a Fronius Primo inverter to Azure services, translating SunSpec Modbus registers into IEEE 2030.5 field paths such as Active Power $O:=\{S,D,R,\ldots\}$8 DERStatus/W and Reactive Power $O:=\{S,D,R,\ldots\}$9 DERStatus/VAR (Leniston et al., 5 Jun 2025). The cloud supports telemetry ingestion, remote curtailment, dynamic configuration through updateGatewayCache, and Volt-VAR Curve deployment, so that cloud-to-edge-to-device updates modify local voltage regulation behavior during operation.

Cloud infrastructure itself also becomes the application domain. C2MS controls dynamic cloudlets of servers, extending Ganglia with group abstraction, SSH-based command execution, CPU temperature monitoring, and PDU-based power measurement (McGilvary et al., 2013). Optimal Dynamic Cloud Network Control addresses service delivery over distributed cloud networks with communication and computation resources, where the “plant” comprises queues, function chains, and resource levels at nodes and links (Feng et al., 2017). The pervasive controller for geotemporal inputs treats geographically distributed data centers as the object of receding-horizon control under volatile electricity prices and temperatures (Lučanin et al., 2018). At the user edge, $<SDR>aaS$0-Control addresses informational self-determination by giving individuals overview, migration, replication, access-control, and autarky across trust domains and directories $<SDR>aaS$1 (Spillner et al., 2012).

6. Empirical results, limitations, and open directions

Empirical CCS results are highly application-dependent, but they illustrate recurring tradeoffs between latency, computation, and robustness. In the vehicular monitoring simulator, for a $<SDR>aaS$2 KB image at $<SDR>aaS$3, reported timings were $<SDR>aaS$4 seconds for Raspberry Pi to RSU transfer, $<SDR>aaS$5 seconds for RSU to cloud transfer, $<SDR>aaS$6 seconds for face extraction, and $<SDR>aaS$7 seconds for license plate extraction, indicating quasi-real-time feasibility but also showing OCR-style recognition as the bottleneck (Hammoudi et al., 2014). In SGX-secured cloud control, average times were $<SDR>aaS$8 for enclave creation, $<SDR>aaS$9 for the dynamic output feedback controller, $T=0$0 for AES-GCM encryption, $T=0$1 for AES-GCM decryption, and $T=0$2 for enclave entry/exit overhead, with total average CPU time about $T=0$3 versus $T=0$4 for the insecure implementation; the authors describe the added overhead as negligible in the context of control-loop operation (Naseri et al., 2021).

Platform studies likewise quantify practical feasibility. DPCCS reports average cloud-edge communication delays around $T=0$5 s, maximum delay less than $T=0$6 s, and packet loss between $T=0$7 and $T=0$8, which the authors deem acceptable for predictive cloud control over UDP (Gao et al., 2021). C2MS evaluation on Amazon EC2 reports page load times in milliseconds, overhead close to, if not zero, and an approximate speedup of $T=0$9 at $T>0$0 nodes/processors when using parallel command execution rather than serial SSH (McGilvary et al., 2013). For geographically distributed cloud management, the pervasive controller estimates $T>0$1 total energy cost savings relative to a baseline dynamic VM consolidation controller, with baseline total cost $T>0$2, and identifies $T>0$3–$T>0$4 hour forecast windows as most effective (Lučanin et al., 2018). In compliance operations, CCF v4.0 reports a $T>0$5 reduction in redundant auditing in FY2024, $T>0$6 faster external assessment preparation, alignment across $T>0$7 cloud products, and coverage of more than $T>0$8 in cloud business (Sonkar, 16 May 2025).

The limitations are equally consistent. Several systems remain experimental or bounded by the dynamics they can tolerate. The vehicular CCS was tested on a small-scale indoor simulator with one moving node and two cloud nodes rather than a real fleet, and its next steps include real mobile conditions and ns2/ns3 network simulation (Hammoudi et al., 2014). The SGX-based secure controller explicitly excludes side-channel attacks from scope and depends on SGX-capable hardware and attestation infrastructure (Naseri et al., 2021). The review literature notes that CCS latency is roughly in the $T>0$9–$\rightarrow$0 ms range, compared with $\rightarrow$1 ms for edge and $\rightarrow$2–$\rightarrow$3 ms for fog, making CCSs more suitable for slow dynamics, water control, energy systems, and long-horizon planning than for ultrafast loops such as robotic arms or vehicle stability control (Ali et al., 11 Sep 2025).

Open directions increasingly converge on hybridization rather than pure cloud centralization. The review literature calls for cloud-edge-fog combinations, better task offloading, more practical encrypted LQG and quadratic optimization, AI and ML integration, stronger incident response and backup strategies, and systematic reduction of encryption and decryption overhead (Ali et al., 11 Sep 2025). Governance and sovereignty work adds another trajectory: future CCS design is likely to treat privileged access, evidence generation, cryptographic custody, and recovery authority as first-class control variables rather than external compliance constraints (Stark et al., 15 Apr 2026). A plausible implication is that the mature CCS is no longer simply a controller moved to the cloud, but a layered cloud-aware control plane that simultaneously manages timing, computation, trust, evidence, and recovery.