Edge–Cloud Platforms, IoT and Digital Twins

Introduction

Cyber-physical systems (CPS) connect physical processes with computation, communication and control. Sensors observe machines and environments; communication networks transport observations; software interprets data; and actuators influence the physical world. The resulting systems are increasingly distributed across edge, fog and cloud platforms rather than being implemented in one computer.

This architectural shift is driven by the growth of industrial IoT (IIoT), autonomous machines, connected infrastructure and data-intensive engineering. A modern production line may require millisecond control locally, fleet-wide optimization in a cloud platform, and intermediate processing at a factory gateway. A digital twin then provides a persistent computational representation of the physical asset, process or system, allowing engineers to monitor condition, simulate alternatives, predict failures and optimize the lifecycle.

The central design challenge is not simply collecting more data. It is deciding where computation should occur, how data should be transported and governed, how models should remain synchronized with reality, and how decisions can be made safely when communication or software services fail.

Learning objectives

After studying this chapter, students should be able to:

1. Distinguish edge, fog and cloud computing and select an appropriate placement of functions.
2. Explain IoT connectivity, messaging, device management and data pipelines.
3. Design a layered edge–cloud architecture for a mechatronic system.
4. Define digital twins and distinguish them from digital models and digital shadows.
5. Construct a basic twin using state estimation, telemetry, simulation and event history.
6. Evaluate latency, bandwidth, reliability, cybersecurity, interoperability and lifecycle concerns.
7. Analyze a practical industrial application and justify engineering decisions.

1. Computing across edge, fog and cloud

1.1 The three computational domains

Edge computing places computation close to the data source or actuator. Examples include a programmable logic controller (PLC), robot controller, industrial gateway, embedded computer or smart sensor. Edge computation is appropriate for deterministic control, safety interlocks, signal conditioning and rapid anomaly detection.

Fog computing is an intermediate distributed layer between local devices and centralized cloud services. A fog node may be a plant server, site gateway, regional data center or network appliance. Fog systems aggregate data from several edge nodes and provide local coordination, buffering, analytics and policy enforcement.

Cloud computing provides elastic, shared and centrally managed computing and storage. It is well suited to fleet-wide analytics, long-term data retention, model training, enterprise integration, digital-twin repositories and large-scale optimization. Cloud services, however, depend on network availability and may introduce variable latency.

The layers are complementary. A cloud platform should not be used for a control loop that must remain safe during a network outage. Conversely, storing every raw vibration sample permanently at the edge may prevent useful fleet-level learning. Good architecture assigns each function according to timing, data volume, availability, privacy, computational demand and consequence of failure.

1.2 Latency and bandwidth reasoning

For a data item transmitted through a network, an approximate end-to-end delay is:

Here, T_sense is sensing and sampling delay, T_queue is waiting time, T_process is computation time, T_transmit is serialization and transmission time, T_propagate is signal propagation delay, and T_actuate is actuator response time. All terms are measured in seconds. The expression is an engineering approximation; actual systems may include retransmissions, operating-system scheduling and protocol overhead.

If a message contains L bits and the effective link rate is R bits per second, the serialization component is:

This formula assumes a continuously available link and excludes protocol headers, contention and retransmission. For example, a 2,000-byte message contains 16,000 bits. At an effective rate of 10 Mbit/s, its serialization time is 0.0016 s, or 1.6 ms. The practical end-to-end delay will be greater because of queueing, processing and propagation.

The approximate data rate generated by N devices, each producing [[MATH;s]] samples per second with [[MATH;b]] bits per sample, is:

where D is bits per second. Headers, timestamps, retransmissions and metadata must be added in a real design. This estimate helps determine whether raw data should be transmitted, compressed, summarized or analyzed locally.

1.3 Placement decisions

A function belongs close to the edge when it has strict timing requirements, must continue during disconnection, involves safety, or processes high-rate data that is expensive to transmit. Cloud placement is attractive when a function requires large computational resources, combines data from many assets, or benefits from centralized model management. Fog placement is useful when several machines need coordinated but locally available services.

A practical decision sequence is:

1. Identify the physical consequence of delay or incorrect action.
2. Determine the required sampling, response and availability characteristics.
3. Estimate data volume and communication cost.
4. Identify privacy, sovereignty and cybersecurity constraints.
5. Decide which functions require autonomous local operation.
6. Design degraded modes for network or service failure.

This process prevents the common mistake of treating cloud connectivity as a substitute for control-system engineering.

2. IoT connectivity and data pipelines

2.1 Device, network and application layers

An IoT system normally contains four functional layers:

• Things: sensors, actuators, controllers and machines.
• Connectivity: wired or wireless networks, addressing, routing and transport.
• Platform services: device registry, identity, message broker, storage and processing.
• Applications: dashboards, alarms, maintenance systems, digital twins and control-support tools.

Industrial systems often combine fieldbuses, industrial Ethernet, Wi-Fi, cellular networks and low-power wireless technologies. Protocol choice depends on distance, determinism, power, mobility, interoperability and security. A protocol that is effective for a battery-powered environmental sensor may be unsuitable for motion control.

2.2 Messaging patterns

Common communication patterns include:

• Request–response: a client asks for information and a server replies. It is intuitive but can create coupling and dependence on immediate availability.
• Publish–subscribe: devices publish messages to topics and consumers subscribe to relevant topics through a broker. It supports decoupling and scalable distribution.
• Command–response: an authorized service issues a command and the device reports acceptance, execution and result separately.
• Streaming: a continuous sequence of time-stamped data is processed by one or more consumers.

Message design should specify a unique device identity, timestamp, measurement, unit, quality indicator, sequence number and schema version. A value of “72” is not useful without knowing whether it represents °C, percent, rpm or a coded state.

2.3 Reliable data pipelines

A robust pipeline commonly performs the following operations:

1. Acquire and time-stamp data.
2. Validate range, type, calibration status and temporal order.
3. Normalize units and names.
4. Filter or aggregate data when justified.
5. Enrich messages with asset, location and operating-context metadata.
6. Buffer during network interruption.
7. Route data to real-time, historical and analytical destinations.
8. Monitor freshness, completeness and quality.

A useful distinction is between data rate and information value. High-frequency raw data may be valuable for fault diagnosis but unnecessary for an operational dashboard. Edge feature extraction can reduce bandwidth, but it may also remove evidence needed later to discover an unknown fault. Retention policies should therefore preserve raw or moderately processed data for selected events and representative periods.

A simple completeness measure for an expected set of records is:

where C is completeness, and n_received and n_expected are counts over a defined time interval. The measure assumes that expected records are known and equally weighted. It does not prove that the received values are correct.

2.4 Time, identity and semantics

Digital twins depend on trustworthy time. Clock drift can produce false causal relationships between vibration, temperature and commands. Systems should use synchronized clocks where feasible and retain both device time and ingestion time. Sequence numbers help detect loss and reordering.

Identity has at least three dimensions: the physical asset identity, the network identity and the software identity. A motor may have a manufacturer serial number, a device certificate, a gateway address and a twin identifier. These relationships must be managed explicitly.

Semantic interoperability means that systems agree on what data means, not merely how bytes are encoded. Units, engineering limits, asset hierarchies, operating modes and relationships should be represented using consistent information models. Without semantics, integration becomes a collection of fragile point-to-point conversions.

3. Digital twins

3.1 Definitions and distinctions

A digital model is a computational representation of an object or process. It may exist without an automated connection to a physical asset. A digital shadow is a representation in which changes in the physical system are reflected digitally, generally in one direction. A digital twin is a persistent digital representation that is connected to a specific physical counterpart and supports synchronization, analysis or interaction across the lifecycle.

The term is used broadly, so a rigorous engineering description should state:

• the physical scope of the twin;
• the variables represented;
• the update direction and frequency;
• the models and assumptions used;
• the intended decisions;
• the confidence and uncertainty of outputs;
• the owner and lifecycle status.

A twin is not simply a three-dimensional visualization. It may include geometry, telemetry, state estimates, physics-based equations, maintenance history, control limits, work orders and simulated future behavior.

3.2 Twin architecture

A practical twin contains five interacting elements:

1. Physical asset: the machine, process or environment.
2. Observation layer: sensors, inspections, events and maintenance records.
3. Data and identity layer: time-series storage, asset relationships and metadata.
4. Model layer: physics models, empirical models, rules and machine-learning models.
5. Decision and interaction layer: alarms, predictions, simulation, optimization and authorized commands.

Figure: A layered architecture in which local functions remain available while data and models move toward fog and cloud services.

3.3 State estimation and synchronization

A physical state is often not directly measurable. For a discrete-time linear system, a simplified state-space model is:

Here, x_k is the state vector at time step [[MATH;k]], u_k is the input, y_k is the measured output, and A, B and C are system matrices. w_k and v_k represent process and measurement errors. This model assumes a linear approximation, discrete sampling and appropriately defined dimensions. State estimators such as the Kalman filter can combine predictions with measurements, but their quality depends on model validity, noise assumptions and sensor calibration.

For nonlinear or complex systems, engineers may use nonlinear observers, reduced-order physics models, finite-element models, rules or machine-learning estimators. A twin should expose uncertainty rather than presenting every estimate as an unquestionable fact.

3.4 Twin fidelity and purpose

Fidelity should be matched to the decision. A high-fidelity thermal model may be valuable for design but too slow for real-time monitoring. A reduced model may support control and maintenance decisions while omitting details irrelevant to those decisions. Important fidelity dimensions include spatial resolution, temporal resolution, physical phenomena, parameter accuracy and validation evidence.

A twin can support four common activities:

• Monitoring: describing present condition and operational context.
• Simulation: exploring behavior under proposed inputs or conditions.
• Prediction: estimating future states, degradation or failure risk.
• Optimization: selecting operating or maintenance decisions subject to constraints.

4. Worked design example: predictive monitoring of a pump

Consider an illustrative centrifugal pump equipped with a vibration sensor, temperature sensor, pressure sensors and motor-current measurement. The objective is to detect developing bearing or cavitation problems while preserving local operation during cloud disconnection.

The vibration sensor samples at 10 kHz with 16-bit values. The raw rate for one channel is:

This is approximately 20 kB/s before protocol overhead, or about 1.7 GB per day if transmitted continuously. Sending all raw data to the cloud is unnecessary for routine monitoring. The edge computer therefore calculates RMS vibration, crest factor and selected spectral features every minute, while retaining raw windows when an alarm threshold is crossed.

For a set of N vibration samples [[MATH;x_i]], the root-mean-square value is:

The samples must have the same unit, such as mm/s or g, and the window must be defined. RMS summarizes signal magnitude but does not identify every fault; frequency-domain features and operating context may also be required.

The architecture is as follows:

• The PLC preserves pump interlocks and emergency shutdown functions.
• The edge computer validates sensors, computes features and detects immediate anomalies.
• A site gateway buffers records and forwards them using authenticated publish–subscribe messaging.
• The cloud stores historical records for the pump and comparable pumps.
• A digital twin links asset identity, operating state, maintenance history, measurements and a degradation model.
• A maintenance application presents a condition score together with evidence, uncertainty and recommended inspection.

Suppose the pump normally operates between 1,450 and 1,500 rpm. A vibration increase may be harmless during startup but significant at stable speed. The twin therefore relates vibration to speed, flow, pressure and temperature rather than applying one threshold to all conditions.

A simple residual is:

where y_k is the measured value and ŷ_k is the model prediction at time [[MATH;k]]. The residual is meaningful only if the model includes relevant operating variables and the measurement uncertainty is understood. A persistent residual may indicate degradation, sensor error, changed operating conditions or model inadequacy.

The outcome is not an automatic replacement decision. Instead, the system generates a ranked inspection recommendation. A technician verifies lubrication, alignment and operating conditions. Confirmed findings are fed back into the maintenance record and used to improve the model. This human-in-the-loop design reduces the risk of treating statistical correlation as proof of mechanical failure.

5. Security, governance and operational responsibility

Connecting machines expands the attack surface. Threats include stolen credentials, insecure firmware, exposed services, manipulated sensor data, ransomware, denial of service and unauthorized commands. A safe architecture applies defense in depth:

• unique device identities and certificate-based authentication;
• least-privilege authorization;
• encryption in transit and, where appropriate, at rest;
• signed firmware and controlled updates;
• network segmentation between enterprise, plant and safety functions;
• secure boot and protected key storage;
• vulnerability management and logging;
• backup, recovery and offline operating procedures;
• explicit command authorization and rate limits.

Confidentiality is important, but integrity and availability may be more important for industrial control. A forged temperature value can lead to unsafe action; a delayed command can be as harmful as a lost command. Safety functions should not depend solely on cloud services, and cybersecurity risk assessment should be integrated with functional safety engineering.

Governance must address ownership, retention, access, provenance and model accountability. Data from a machine may involve employees, suppliers or customers. Privacy regulations may apply to location, operator activity or biometric information. Cross-border cloud storage may create legal and contractual constraints.

Digital-twin outputs can influence maintenance, production and safety decisions. Therefore, organizations should record model versions, training data, calibration status, confidence, overrides and decision outcomes. Explainability is especially important when an AI model produces a maintenance recommendation. AI can assist anomaly detection, remaining-useful-life estimation and model calibration, but it should not silently replace validated safety logic.

6. Validation, performance and lifecycle management

A twin must be validated at several levels:

1. Data validation: Are measurements calibrated, complete, time-aligned and physically plausible?
2. Model validation: Does the model reproduce relevant behavior under representative conditions?
3. Operational validation: Does it support the intended engineering decision?
4. Lifecycle validation: Does performance remain acceptable after maintenance, software updates or process changes?

Useful metrics include latency, data completeness, availability, false-alarm rate, missed-detection rate, prediction error, energy consumption and maintenance benefit. No single metric is sufficient. For example, reducing false alarms by suppressing all alerts is not an improvement.

Model drift occurs when the relationship between inputs and outcomes changes. Causes include equipment aging, sensor replacement, new materials, changed operating policy and environmental variation. Drift monitoring should trigger investigation, recalibration or retraining. Retraining should use controlled data and preserve a rollback version.

Interoperability remains a major challenge. Vendors may expose different data models, naming schemes and update mechanisms. Open standards and well-documented APIs reduce dependence on proprietary interfaces, but standards do not remove the need for semantic mapping and engineering verification.

7. Contemporary developments and professional practice

Current systems increasingly use containerized edge applications, hardware accelerators, event-stream processing and federated or distributed learning. These technologies can reduce data movement and improve responsiveness, but they add software supply-chain, deployment and verification complexity. Digital threads connect engineering requirements, design data, operational telemetry, maintenance records and end-of-life information. This supports traceability across the product lifecycle.

A professional engineer should begin with the decision and risk, not the platform brand. The following practices are broadly applicable:

• define measurable use cases and acceptance criteria;
• keep safety-critical control local and deterministic;
• use a canonical asset and semantic model;
• separate raw data, derived features, predictions and commands;
• design for intermittent connectivity and graceful degradation;
• make time, units, quality and provenance explicit;
• validate models against operating regimes, not only average conditions;
• monitor both technical performance and business or maintenance outcomes;
• secure the complete lifecycle, including retirement and credential revocation;
• involve operators and maintenance personnel in system design.

Challenges and limitations

Edge–cloud architectures can reduce latency and improve scalability, but they create distributed-system problems: inconsistent state, partial failure, clock differences, software version mismatch and difficult debugging. More sensors do not automatically produce better decisions; poor calibration and weak semantics can increase confusion. Cloud elasticity can conceal long-term cost, and dependence on a vendor can limit portability.

Digital twins also have epistemic limits. A model is not the physical system. Unobserved faults, unknown disturbances and changing conditions can invalidate predictions. High-fidelity models may require parameters that are unavailable or expensive to identify. Machine-learning models may perform well on historical data but fail under rare events. Consequently, twin outputs must be interpreted with uncertainty, engineering judgment and clearly defined operating boundaries.

Chapter Summary

Edge computing provides rapid, local and resilient processing; fog computing coordinates devices and services at a site or regional level; and cloud computing supplies scalable storage, analytics and fleet-wide integration. Function placement should be based on timing, bandwidth, availability, safety, privacy and computational requirements.

IoT data pipelines require trustworthy identity, time, units, schemas, quality indicators, buffering and semantic interoperability. A digital twin is a connected, persistent representation of a physical counterpart, not merely a visualization. It combines observations, models, history and decisions for monitoring, simulation, prediction and optimization.

State-space models and residuals provide useful foundations for estimation, but every model depends on assumptions and validation. Secure architectures preserve local safety, authenticate devices, protect data and govern commands. AI can enhance twin capabilities, yet uncertainty, drift, explainability and human responsibility remain essential. Effective systems are designed around engineering decisions and lifecycle outcomes rather than data collection alone.

Key Terms

Edge computing: Processing performed near the data source or actuator.

Fog computing: Intermediate distributed computing between edge devices and cloud services.

Cloud computing: Elastic, centrally managed computing and storage services.

Industrial IoT: Internet-connected sensing, control and analytics for industrial systems.

Digital model: A computational representation that may not be connected to a physical asset.

Digital shadow: A digital representation updated by a physical system, usually in one direction.

Digital twin: A persistent connected representation of a specific physical counterpart.

Telemetry: Time-stamped measurements transmitted from a device.

Publish–subscribe: Messaging pattern in which publishers send topic messages through a broker to subscribers.

Data pipeline: A sequence of acquisition, validation, transformation, storage and analysis operations.

Semantic interoperability: Agreement on the meaning and context of exchanged data.

State estimation: Inferring internal system state from models and measurements.

Residual: Difference between a measured value and a model prediction.

Model drift: Reduction in model validity caused by changing data or operating conditions.

Data completeness: Proportion of expected records that are received.

Digital thread: Traceable information linking lifecycle stages and engineering activities.

Graceful degradation: Continued safe operation with reduced capability after partial failure.

Fleet analytics: Analysis of data from multiple related assets.

Review Questions

Short Answer Questions

1. What distinguishes edge computing from cloud computing?
2. Why are timestamps, units and quality indicators important in IoT messages?
3. Define a digital twin and distinguish it from a digital model.
4. What is the purpose of buffering at a fog or edge node?
5. Why should safety-critical control normally remain local?

Long Answer Questions

1. Explain how latency, bandwidth, availability and safety influence edge–fog–cloud function placement.
2. Describe a complete IoT data pipeline from sensor acquisition to digital-twin decision support.
3. Explain the role of state estimation in a digital twin and discuss the assumptions of a linear state-space model.
4. Discuss cybersecurity and governance requirements for an industrial digital-twin platform.
5. Compare physics-based, data-driven and hybrid models for condition monitoring.

Analytical / Application Questions

1. A factory has 40 sensors, each producing 2,000 samples/s at 16 bits/sample. Calculate the ideal raw data rate using D = N × s × b, and recommend which processing functions should occur at the edge.
2. Design an edge–fog–cloud architecture for an autonomous warehouse vehicle. Identify functions that must remain local and justify the treatment of historical data and fleet optimization.
3. A pump twin reports increasing residuals, but the pump has recently received a new sensor and operates at a different speed range. Analyze at least four possible explanations and propose a validation plan before authorizing maintenance.

Multiple Choice Questions with Answers

Question 1

Which function is most appropriately located at the edge?

A. Fleet-wide historical trend analysis

B. Emergency interlock processing

C. Long-term archival storage

D. Cross-site production benchmarking

Correct Answer: B. Emergency interlock processing

Question 2

A message contains 2,000 bytes and the effective link rate is 10 Mbit/s. Ignoring overhead, what is its serialization time?

A. 0.16 ms

B. 1.6 ms

C. 16 ms

D. 160 ms

Correct Answer: B. 1.6 ms

Question 3

Which feature is essential for meaningful industrial telemetry?

A. A value without a unit

B. A timestamp and quality indicator

C. A decorative 3D model

D. An unversioned data format

Correct Answer: B. A timestamp and quality indicator

Question 4

What best distinguishes a digital twin from a digital model?

A. The twin must always contain 3D geometry

B. The twin is connected to a specific physical counterpart

C. The model must run only in the cloud

D. The twin cannot contain simulations

Correct Answer: B. The twin is connected to a specific physical counterpart

Question 5

In the equation r_k = y_k − ŷ_k, what does r_k represent?

A. The model input

B. The sampling frequency

C. The residual between measurement and prediction

D. The actuator command

Correct Answer: C. The residual between measurement and prediction

Question 6

Which messaging pattern decouples producers from multiple consumers through topics?

A. Publish–subscribe

B. Direct memory access

C. Point-to-point wiring only

D. Batch compilation

Correct Answer: A. Publish–subscribe

Question 7

Why might raw vibration data be retained only when an alarm occurs?

A. To eliminate the need for timestamps

B. To reduce routine bandwidth and storage while preserving diagnostic evidence

C. To prevent any later analysis

D. To make sensor calibration unnecessary

Correct Answer: B. To reduce routine bandwidth and storage while preserving diagnostic evidence

Question 8

Which statement about cloud control of a safety-critical actuator is most appropriate?

A. It is always preferred because cloud computers are powerful

B. It should replace all local interlocks

C. It may be unsuitable because communication failure can compromise timely safe action

D. It removes the need for cybersecurity

Correct Answer: C. It may be unsuitable because communication failure can compromise timely safe action

Question 9

What is model drift?

A. A deliberate increase in sampling rate

B. A change that reduces the validity of a model under new conditions

C. A method of encrypting telemetry

D. A physical relocation of a cloud server

Correct Answer: B. A change that reduces the validity of a model under new conditions

Question 10

For 40 sensors producing 2,000 samples/s at 16 bits/sample, what ideal raw data rate results?

A. 1.28 Mbit/s

B. 12.8 Mbit/s

C. 128 Mbit/s

D. 1.28 Gbit/s

Correct Answer: B. 12.8 Mbit/s