Edge, Fog, and Cloud Platforms

Introduction and Context

An Internet of Things (IoT) system is not simply a collection of sensors connected to the internet. It is a distributed computing system in which physical devices sense conditions, perform actions, exchange data, and participate in software-controlled operations. In mechatronics, these devices include programmable logic controllers, robotic joints, motor drives, machine-vision cameras, temperature sensors, encoders, and supervisory control systems.

The location at which data is processed strongly affects latency, bandwidth consumption, reliability, privacy, safety, and maintainability. Three architectural locations are commonly distinguished:

• Edge: computation performed close to the physical device, often in a sensor, controller, gateway, industrial computer, or robot.
• Fog: an intermediate distributed layer between devices and centralized cloud services, such as a factory gateway, plant server, or regional computing node.
• Cloud: centralized or geographically distributed data-center services used for large-scale storage, analytics, application hosting, and fleet management.

A practical architecture normally uses all three. A motor controller may close a safety loop locally; an edge gateway may filter vibration data; a cloud platform may compare the health of thousands of machines.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish edge, fog, and cloud computing and select an appropriate processing location.
2. Design a secure device-provisioning and identity-management workflow.
3. Explain edge processing, cloud ingestion, message brokers, databases, and event-driven services.
4. Apply containers and serverless functions appropriately.
5. Design remote configuration and over-the-air update procedures.
6. Select observability metrics and reason about reliability, latency, and operational risk.
7. Evaluate an IoT platform architecture for safety, security, scalability, and maintainability.

1. The Distributed IoT Computing Model

A useful abstraction is a pipeline:

physical process → device sensing → local control → edge gateway → fog services → cloud platform → applications and operators

The pipeline is not necessarily linear. Commands and configuration travel in the opposite direction, while alarms may be sent simultaneously to a local operator and a cloud service.

Edge computing

Edge computing places computation near the source or consumer of data. Examples include debouncing a switch, filtering an accelerometer signal, detecting an over-temperature condition, or executing a real-time control loop. Edge processing reduces network traffic and can continue during an internet outage.

Edge systems have limited memory, processing power, and energy. They may also be physically accessible to attackers. Their software must therefore be compact, fault tolerant, updateable, and capable of operating with intermittent connectivity.

Fog computing

Fog computing provides intermediate computing and networking resources. A fog node may aggregate several machines, maintain a local time-series database, host a dashboard, or coordinate production-line devices. Fog processing is particularly useful when a factory needs plant-wide coordination but cannot depend on a remote cloud for every decision.

Fog is not merely a slower version of edge computing. It commonly provides more storage, virtualization, orchestration, and network management than individual devices while remaining closer to the process than a distant cloud.

Cloud computing

Cloud platforms provide elastic computing, object storage, managed databases, identity services, message brokers, event routing, monitoring, and machine-learning tools. They are valuable for long-term data analysis, cross-site benchmarking, digital-twin applications, and fleet-wide software management.

Cloud services introduce dependence on connectivity, provider availability, service configuration, and recurring cost. Cloud processing must not be used as the sole protection for a hazardous physical process when network delay or interruption could create danger.

Placement criteria

Processing placement should be determined by requirements rather than fashion. Important criteria include:

For a control action, total response time can be represented as:

Here, T_sense is sensing and sampling delay, T_compute is processing delay, T_network is communication delay, and T_actuate is actuator delay. All quantities are measured in seconds. The expression is a simplified engineering model: queueing, retransmissions, operating-system scheduling, and jitter may make the actual delay variable. A safety-critical loop should therefore be validated using worst-case or bounded delay, not merely an average.

2. Device Identity and Provisioning

Provisioning is the process of preparing a device to join a platform securely. It includes identity creation, credential installation, authorization, configuration, and registration of device metadata.

A robust lifecycle has these stages:

1. Manufacturing identity: Each device receives a unique identifier and cryptographic key or certificate. The private key should be generated in, or protected by, a secure element where practical.
2. First connection: The device authenticates to a provisioning service using its bootstrap credential.
3. Authorization: The service verifies that the device is genuine, approved, and associated with the correct organization or site.
4. Operational credentials: The device receives a restricted certificate, token, or key for normal operation.
5. Registration: Metadata such as model, firmware version, location, capabilities, and ownership is recorded.
6. Lifecycle control: Credentials can be rotated, suspended, revoked, and replaced when the device is transferred or decommissioned.

Authentication answers “Who is this device?” Authorization answers “What may it do?” These must not be confused. A device may be authenticated yet forbidden to command a production robot.

Least privilege and topic authorization

Message-broker permissions should be expressed as narrowly as possible. A temperature sensor might publish to site/line3/motor7/telemetry and read site/line3/motor7/config, but it should not publish commands to other motors. Operators and applications should receive separate roles. Wildcard permissions should be reviewed carefully because they can unintentionally grant access to an entire fleet.

Data representation

Telemetry should include a timestamp, device identifier, measurement, unit, quality indicator, and firmware or schema version where relevant. Time synchronization is important for correlating events. A measurement without a unit or timestamp is difficult to interpret safely.

3. Edge Processing and Local Resilience

Edge processing transforms raw data before transmission. Common operations include:

• range and plausibility checks;
• calibration and unit conversion;
• filtering and aggregation;
• feature extraction, such as root-mean-square vibration;
• local threshold detection;
• buffering during disconnection;
• local control and safe-state transition.

Filtering must be designed with awareness of its effect on latency and signal shape. A moving average can suppress noise but delay abrupt changes. A safety alarm may require a faster path than a trend display.

A useful design pattern is dual-path processing. The fast path makes local decisions, while the analytic path stores or transmits richer information for diagnosis. For example, an edge controller can stop a motor immediately when a guard switch opens, while sending a compressed vibration feature every second and a short waveform whenever an anomaly is detected.

Store-and-forward buffering allows data to survive temporary outages. The design should define buffer capacity, retention policy, ordering behavior, duplicate handling, and what happens when the buffer is full. Messages should carry an event identifier so that cloud services can recognize retransmissions.

4. Cloud Ingestion and Message Brokers

A message broker decouples producers from consumers. Devices publish messages, and services subscribe to relevant topics or queues. This permits independent scaling and prevents a device from needing to know every application that uses its data.

Common messaging patterns include:

• Publish/subscribe: One message can be delivered to multiple subscribers.
• Queue: A message is normally processed by one member of a consumer group.
• Request/response: A client sends a request and expects a correlated reply.
• Event notification: A producer announces that something happened without prescribing how it is handled.

Delivery semantics must be explicit:

• At most once: Messages may be lost but are not intentionally retried.
• At least once: Messages are retried until acknowledged, so duplicates are possible.
• Exactly once: Processing appears once under defined system assumptions; it is difficult to guarantee across independent systems.

Because at-least-once delivery is common, consumers should be idempotent: processing the same event again should not create an incorrect additional effect. This can be achieved with a unique event identifier and a recorded processing status.

A broker is not a database. It transports messages and may retain them temporarily, whereas a database supports durable query and analysis. A production system commonly uses both.

Ingestion pipeline

A typical cloud ingestion sequence is:

1. A device publishes a validated message over an authenticated connection.
2. An ingestion endpoint checks identity, schema, size, and rate limits.
3. The broker routes the message to raw storage, real-time processing, and alerting consumers.
4. A stream processor enriches the event with asset metadata and evaluates rules.
5. Data is stored in an appropriate database.
6. Applications display status, generate work orders, or invoke control policies.

Schema validation is essential. A platform should reject malformed data or route it to a quarantine stream rather than allowing it to corrupt operational databases.

5. Databases for IoT Data

Different questions require different storage models.

A time-series record commonly contains device identity, timestamp, value, unit, quality, and tags. High-cardinality tags, excessive sampling, and indefinite retention can make storage expensive. Retention tiers are therefore useful: recent high-resolution data may remain online, while older data is aggregated or moved to lower-cost storage.

For a time interval of duration Δt sampled at frequency f_s, the approximate number of samples is:

Here, N is dimensionless, f_s is in samples per second, and Δt is in seconds. This estimate assumes regular sampling and excludes protocol overhead. If 100 sensors sample at 10 Hz for 24 hours, the approximate sample count is 100 × 10 × 86,400 = 86,400,000 samples. The value is an estimate for capacity planning, not a guarantee of actual records after filtering or loss.

6. Event-Driven Services, Containers, and Serverless Functions

An event-driven architecture reacts to events such as temperature.high, device.registered, or firmware.completed. An event should describe a fact that occurred, rather than tightly coupling the producer to a particular internal function.

A rule engine may route a high-temperature event to an alarm service, maintenance system, and notification service. Independent consumers can evolve without changing the device firmware.

Containers

A container packages an application and its dependencies while sharing the host operating system kernel. Containers provide consistent deployment, isolation, version control, and efficient use of resources. They are suitable for edge gateways, protocol adapters, stream processors, and services with predictable long-running behavior.

Container security requires minimal images, non-root execution where possible, vulnerability scanning, signed images, restricted capabilities, resource limits, and controlled access to host devices. Containers are not equivalent to virtual machines and should not be treated as a complete security boundary in every threat model.

Serverless functions

A serverless function is a short-lived, provider-managed execution unit triggered by an event, request, schedule, or message. It is useful for data transformation, notification, metadata updates, and automation with variable demand. The operator generally pays for execution or allocated resources rather than maintaining a continuously running server.

Limitations include startup delay, execution-time limits, provider-specific interfaces, difficult local debugging, and complications for stateful or real-time workloads. A serverless function should not directly perform a safety-critical actuator action without an independent, deterministic safety layer.

7. Remote Configuration and Over-the-Air Updates

Remote configuration changes operating parameters without replacing the entire application. Configuration must be versioned, validated, scoped, and auditable. Parameters should have declared type, unit, range, default, owner, and rollback behavior.

A safe configuration workflow is:

1. propose a change;
2. validate syntax, range, compatibility, and authorization;
3. stage it for a device group;
4. apply it atomically or transactionally;
5. verify reported state and behavior;
6. expand gradually or roll back.

Over-the-air (OTA) updates replace firmware or application software remotely. A secure OTA design uses signed packages, encrypted transport, version checks, compatibility checks, resumable transfer, sufficient power and storage, and a recovery mechanism. The device must verify the package signature before execution; encryption alone does not prove who produced the software.

A/B partitioning stores the current and candidate images separately. The device boots the candidate image, performs health checks, and marks it valid only after successful startup. If the check fails, a bootloader can revert to the previous image. Updates should be deployed by canary groups before fleet-wide release.

Operational records should include target population, package hash, signature status, start time, completion status, failure reason, and rollback result. A device that reports “download complete” has not necessarily installed or successfully executed the update.

8. Observability and Operational Reliability

Observability is the ability to infer internal system behavior from outputs. It combines:

• Metrics: numerical time-series such as message rate, latency, CPU use, battery level, and update success rate.
• Logs: structured records of events and errors.
• Traces: correlated paths through multiple services.
• Events and alerts: operationally significant state changes.

A useful telemetry record includes a correlation identifier, device identifier, service name, timestamp, severity, software version, and relevant context. Sensitive values should not be written into logs unnecessarily.

Important service-level indicators include ingestion success, message age, command latency, data completeness, device connectivity, and update failure rate. An availability estimate over an observation period is:

where A is availability, U is time the service is usable, and T is total observation time, with both time quantities in the same units. For example, 99 hours usable in a 100-hour period gives A = 0.99, or 99%. This simple measure does not capture severity, performance degradation, or partial regional failure; those require more precise service-level definitions.

Alerts should be actionable and tied to a response procedure. Alerting on every transient sensor error creates fatigue, while failing to alert on stale data can hide a communications failure. Dashboards should distinguish device failure, network failure, broker backlog, processing failure, and database failure.

9. Security, Safety, Ethics, and Governance

IoT platforms connect cyber systems to physical processes, so cybersecurity is also a safety concern. A compromised command path may cause injury, equipment damage, or environmental harm. Defense-in-depth should include secure boot, credential protection, network segmentation, encryption in transit, authorization, patch management, backups, anomaly detection, and incident response.

Important governance questions include:

• Who owns machine and worker data?
• Is monitoring proportionate and transparent?
• How long should data be retained?
• Can a vendor use operational data to train external models?
• How are automated maintenance or control decisions reviewed?
• What evidence is retained for safety and regulatory audits?

Privacy protection includes data minimization, access control, pseudonymization where appropriate, and retention limits. Regulatory obligations vary by jurisdiction and sector; industrial deployments may also be subject to functional-safety, cybersecurity, occupational-safety, and critical-infrastructure requirements.

Artificial intelligence can support anomaly detection and predictive maintenance, but an AI model is not automatically reliable because it produces a probability. Training-data drift, sensor changes, false alarms, and unobserved failure modes must be evaluated. In safety-related applications, AI should normally advise or prioritize human and deterministic control mechanisms unless the complete system has been appropriately assured.

10. Illustrative Case: Connected Pumping Station

Background

A municipal pumping station contains four variable-speed pumps. Each pump has pressure, flow, temperature, vibration, and motor-current sensors. The station must continue safe operation during loss of wide-area connectivity.

Problem

The original system transmitted every raw sample to a remote application. This caused high bandwidth use, slow alarms during network congestion, and difficulty distinguishing sensor failure from pump failure. Firmware updates required on-site visits.

Analysis

Emergency shutdown and anti-cavitation protection require deterministic local response. Long-term comparison of pump efficiency requires historical data across stations. A single processing layer cannot satisfy both requirements.

Approach and solution

Each pump controller performs local range checks and closes the safety loop. An industrial edge computer calculates one-second vibration and efficiency features, stores up to 24 hours of buffered data, and raises a local alarm if pressure or temperature violates a validated limit. A fog server at the station hosts a dashboard, maintains the local asset registry, and coordinates the four pumps.

The cloud ingestion service authenticates each gateway with a device certificate. A broker routes telemetry to a time-series database, raw event storage, and an alert function. At-least-once delivery is accepted; every event contains a unique identifier, and consumers use idempotent processing. A relational database stores work orders and maintenance history.

Software updates are signed and deployed first to one non-critical pump, then to the remaining pumps in stages. Configuration changes require an authorized engineer, include units and limits, and are recorded with an audit trail. Metrics include local alarm latency, gateway buffer depth, message age, broker backlog, database write errors, and OTA success rate.

Outcome

The station can maintain protective operation without cloud connectivity, while the cloud provides fleet-wide maintenance analysis. Network traffic is reduced because raw waveforms are transmitted only when an anomaly is detected. Staged updates reduce the risk of simultaneous fleet failure. The architecture also makes faults more diagnosable because local, fog, and cloud responsibilities are separated.

Learning points

The case demonstrates that edge, fog, and cloud are complementary. Safety functions should remain local; fog services provide site autonomy; cloud services provide scale and historical insight. Identity, idempotency, staged deployment, observability, and explicit failure behavior are as important as selecting a software platform.

11. Design Method and Best Practices

A disciplined design process is:

1. Identify physical hazards, control deadlines, data owners, and failure consequences.
2. Classify functions as safety, control, operational, analytical, or administrative.
3. Place each function according to latency, availability, privacy, and resource requirements.
4. Define device identity, authorization, message schemas, and data ownership before implementation.
5. Choose storage by query pattern rather than by popularity.
6. Design for retries, duplicates, offline operation, clock errors, and partial failures.
7. Automate testing, image scanning, deployment, rollback, and configuration validation.
8. Measure real behavior using metrics, logs, traces, and fault-injection tests.
9. Deploy changes gradually and maintain a tested recovery path.
10. Document assumptions, responsibilities, and operational runbooks.

The most common architectural mistake is to send every decision to the cloud. Other common mistakes are treating a broker as durable business storage, granting broad device permissions, deploying unsigned firmware, ignoring duplicate messages, and measuring only average latency. A dependable platform is designed around failure modes, not only the normal operating case.

Chapter Summary

Edge, fog, and cloud computing form complementary layers of an IoT architecture. Edge devices provide immediate sensing, control, filtering, and safe operation. Fog nodes coordinate a site and support local autonomy. Cloud platforms provide scalable ingestion, storage, analytics, fleet management, and cross-site applications.

Secure provisioning establishes device identity and controlled authorization. Message brokers decouple producers and consumers, but delivery semantics require idempotent processing. Databases should be selected according to data shape and query needs. Containers support portable long-running services, while serverless functions suit event-triggered, variable workloads but are not universal replacements for deterministic control.

Remote configuration and OTA updates require validation, authorization, signatures, staged rollout, health checks, and rollback. Observability combines metrics, logs, traces, and actionable alerts. In mechatronics, cybersecurity and safety are inseparable: cloud services may inform or optimize a process, but protective and time-critical functions must remain dependable during network and platform failures.

Key Terms

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

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

Cloud computing: Elastic, network-accessible computing and storage delivered from data-center infrastructure.

Provisioning: Preparing a device with identity, credentials, authorization, configuration, and registration.

Device identity: A unique cryptographic or logical identity representing a device.

Authentication: Verification of an entity’s identity.

Authorization: Determination of what an authenticated entity may do.

Message broker: Middleware that routes messages between producers and consumers.

Publish/subscribe: Messaging model in which publishers send to topics and subscribers receive relevant messages.

Idempotence: Property whereby repeated processing produces the same intended result as single processing.

Time-series database: Database optimized for timestamped measurements.

Event-driven architecture: Architecture in which services respond to recorded events.

Container: Packaged application process sharing a host operating-system kernel.

Serverless function: Provider-managed, event-triggered execution unit.

Remote configuration: Authorized modification of device parameters without replacing the application.

OTA update: Software or firmware update delivered remotely over a network.

Observability: Ability to infer system behavior from metrics, logs, traces, and events.

Canary deployment: Limited initial deployment used to detect problems before wider rollout.

Store-and-forward: Buffering data locally until a connection becomes available.

Defense in depth: Use of multiple independent protective controls.

Review Questions

Short Answer Questions

1. Define edge, fog, and cloud computing in an IoT context.
2. Why should authentication and authorization be implemented separately?
3. What is the difference between a message broker and a database?
4. Why is idempotent processing important under at-least-once delivery?
5. Name three essential controls for a secure OTA update.

Long Answer Questions

1. Explain how latency, connectivity, resource capacity, and safety influence the placement of an IoT function.
2. Describe a complete device-provisioning lifecycle from manufacturing identity to decommissioning.
3. Compare containers and serverless functions for an industrial edge application.
4. Explain how a time-series database, object storage, and a relational database could work together in a factory platform.
5. Discuss how observability supports diagnosis of device, network, broker, and application failures.

Analytical / Application Questions

1. Design an edge–fog–cloud architecture for a robotic assembly cell. Identify which functions must remain local and justify your choices.
2. A platform receives duplicate temperature events after a gateway reconnects. Propose an ingestion and database strategy that prevents duplicate alarms and explain the role of event identifiers.
3. An OTA update works on 2% of a fleet but causes repeated restarts on 5% of the updated devices. Analyze the immediate containment, diagnostic, rollback, and staged-release actions that should follow.

Multiple Choice Questions with Answers

Question 1

Which function is most appropriately kept at the edge in a safety-critical mechatronic system?

A. Fleet-wide energy benchmarking

B. Long-term storage of vibration waveforms

C. Immediate protective shutdown when a guard opens

D. Training a predictive-maintenance model

Correct Answer: C. Immediate protective shutdown when a guard opens

Question 2

What is the primary purpose of a fog layer?

A. To replace all device controllers

B. To provide intermediate site-level processing and coordination

C. To eliminate the need for device identity

D. To guarantee unlimited cloud storage

Correct Answer: B. To provide intermediate site-level processing and coordination

Question 3

A message is delivered at least once. What property should its consumer preferably have?

A. Idempotence

B. Random execution timing

C. Anonymous access

D. Unlimited message mutation

Correct Answer: A. Idempotence

Question 4

Which storage option is most suitable for high-volume timestamped temperature measurements?

A. Time-series database

B. Image editor

C. Certificate authority

D. Container registry

Correct Answer: A. Time-series database

Question 5

A serverless function is generally most suitable for which task?

A. A deterministic motor safety loop

B. A short event-triggered notification workflow

C. A mechanical emergency brake

D. A sensor’s analog signal conditioning circuit

Correct Answer: B. A short event-triggered notification workflow

Question 6

What does a device signature check provide during an OTA update?

A. Proof that the package came from an authorized signer and was not altered

B. A guarantee that the device has an internet connection

C. Automatic correction of faulty sensors

D. Unlimited storage capacity

Correct Answer: A. Proof that the package came from an authorized signer and was not altered

Question 7

If a system is usable for 99 hours during a 100-hour observation period, its simple availability is:

A. 0.01%

B. 1%

C. 99%

D. 199%

Correct Answer: C. 99%

Question 8

Which practice best limits the impact of a compromised temperature sensor?

A. Granting it permission to command every actuator

B. Using least-privilege authorization for its required topics

C. Disabling all audit logs

D. Sharing one administrator credential across the fleet

Correct Answer: B. Using least-privilege authorization for its required topics

Question 9

What is the principal benefit of store-and-forward buffering?

A. It permits data retention during temporary connectivity loss

B. It guarantees that no message can ever be duplicated

C. It removes the need for local safety logic

D. It converts analog signals into digital signals

Correct Answer: A. It permits data retention during temporary connectivity loss

Question 10

Which set best represents observability signals?

A. Metrics, logs, and traces

B. Motors, gears, and bearings

C. Passwords, invoices, and contracts

D. Voltage, torque, and paint color

Correct Answer: A. Metrics, logs, and traces