Edge, Fog and Cloud IoT Platforms

Introduction and Context

An Internet of Things (IoT) solution is not simply a collection of sensors connected to the internet. It is a distributed computing system in which devices generate data, communication networks transport it, and software platforms interpret it and produce actions. The location at which data is processed strongly affects latency, bandwidth consumption, resilience, privacy, cost and manageability.

Traditional cloud-centred IoT architectures send most device data to remote data centres. This model provides large-scale storage and computing, but it may be unsuitable when decisions must be made within milliseconds, connectivity is unreliable, or sensitive data should remain near its source. Edge and fog computing extend processing closer to devices. A practical IoT architecture therefore distributes responsibilities across devices, gateways, edge nodes, fog platforms and cloud services.

This chapter explains how to design data flows across these layers and how to evaluate the platform capabilities required for professional IoT deployments. It focuses on device registries, message brokers, rules engines, serverless services, containers, storage and platform selection.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Distinguish device, gateway, edge, fog and cloud computing roles.
2. Design an IoT data flow for sensing, processing, storage and actuation.
3. Explain the purpose of device registries, message brokers and rules engines.
4. Compare serverless functions, containers and virtual machines for IoT workloads.
5. Select suitable storage and processing locations using latency, bandwidth, security and cost criteria.
6. Identify operational, ethical, governance and reliability issues in distributed IoT platforms.

1. The Distributed IoT Computing Model

1.1 The layers of an IoT platform

A useful logical model contains five levels:

These are logical rather than strictly physical categories. A gateway may also be an edge node, and a fog platform may use cloud technologies deployed in a local facility. The important design question is not the label but where a function executes and why.

1.2 Device layer

Devices measure physical variables such as temperature, vibration, pressure, location and light. They may also control relays, valves, displays, vehicles or industrial machinery. Devices are usually constrained by battery capacity, processor speed, memory, network availability and physical security.

A device should perform time-critical safety actions locally whenever possible. For example, an industrial controller should stop a motor when an emergency limit is exceeded; it should not depend exclusively on a distant cloud service. Devices may also filter, compress or summarise measurements before transmission.

1.3 Gateway layer

A gateway connects local devices to one or more upstream networks. It commonly performs:

• protocol translation, such as Modbus-to-MQTT or BLE-to-IP;
• device authentication and certificate management;
• buffering during network outages;
• data aggregation and format conversion;
• local access control and firewalling; and
• forwarding of commands to devices.

Gateways are especially important where devices cannot directly use IP networks or where a local network must be isolated from the public internet.

1.4 Edge layer

Edge computing places general-purpose processing near devices. An edge node can run analytics, computer-vision models, rules, dashboards and local APIs. Edge processing reduces the time required to respond and can prevent raw data from leaving a site.

Edge nodes are not automatically more secure than cloud systems. They may be installed in exposed locations, have limited monitoring, and be physically tampered with. Secure boot, encrypted storage, signed software updates and central inventory are therefore essential.

1.5 Fog layer

Fog computing coordinates resources between edge sites and the cloud. A fog layer may provide regional event processing, federated device management, local data sharing and workload scheduling. It is valuable in systems containing many edge sites, such as connected transport corridors, utility substations or geographically distributed factories.

Fog is best understood as a distributed control and service layer rather than merely “a smaller cloud.” It can maintain operation when the central cloud is unavailable while still coordinating several local sites.

1.6 Cloud layer

Cloud platforms provide elastic compute, durable storage, managed databases, identity services, analytics, machine learning and fleet-wide administration. The cloud is suitable for historical analysis, model training, cross-site reporting, software distribution and long-term policy management.

Cloud processing introduces network dependence, possible data-residency concerns and variable operational costs. It should not be used by default for every decision.

2. Designing an IoT Data Flow

A data flow should specify more than an arrow from sensor to cloud. It should identify data types, timing requirements, transformations, destinations, failure behaviour and security controls.

A typical flow is:

1. A device samples a physical variable.
2. The device validates the reading and adds metadata such as device identity, timestamp and measurement unit.
3. A gateway authenticates the device, translates protocols and buffers messages.
4. An edge service filters, aggregates or analyses data.
5. A broker routes messages to subscribers.
6. A rules engine sends selected events to storage, alerting, workflow or control services.
7. A fog service coordinates data and decisions across nearby sites.
8. Cloud services store selected raw or processed data, train models and provide enterprise applications.
9. Commands travel in the reverse direction, with authorisation and confirmation at each important boundary.

2.1 Data classification

Before choosing a destination, classify data according to its purpose:

2.2 Latency and bandwidth reasoning

Latency is the elapsed time between an event and the required response. A control loop that must respond in 20 milliseconds cannot normally depend on an internet round trip with uncertain delay. It belongs at the device or edge.

Bandwidth requirements can be estimated as:

where R is the uncompressed data rate in bits per second, n is the number of sources, f is the sampling frequency in samples per second, and s is the payload size in bytes per sample. The formula assumes every source produces a fixed-size sample at a constant rate and excludes protocol overhead. In practice, headers, encryption, retransmissions and encoding increase the actual rate.

For example, 500 sensors producing 10 samples per second with 16-byte payloads generate:

R = 500 × 10 × 16 × 8 = 640,000 bits per second, or 640 kbit/s before overhead. If an edge service transmits only one 16-byte summary per second per sensor, the corresponding payload rate becomes 64 kbit/s. This illustrates why filtering and aggregation can reduce network cost.

2.3 Reliability and store-and-forward

A distributed system must define what happens when connectivity fails. A gateway may place messages in a persistent queue and forward them after reconnection. Each message should have a timestamp, sequence number and quality indicator. Applications must distinguish:

• at-most-once delivery: a message may be lost but is not redelivered;
• at-least-once delivery: a message may be delivered more than once; and
• effectively-once processing: duplicate effects are prevented through idempotent processing or deduplication.

At-least-once delivery is common because it avoids silent loss, but consumers must tolerate duplicates. An operation is idempotent if repeating it produces the same final state, such as setting a valve to 40% rather than incrementing it twice.

3. Core Platform Services

3.1 Device registries and digital identity

A device registry is an authoritative inventory of devices and their attributes. It may contain a unique identifier, hardware model, owner, location, capabilities, firmware version, certificate reference, lifecycle state and last contact time.

A registry is not merely a database of serial numbers. It supports provisioning, authentication, authorisation, monitoring, replacement and retirement. A sound lifecycle includes:

1. manufacturing or onboarding;
2. identity issuance;
3. secure registration and ownership assignment;
4. operational monitoring;
5. credential rotation and software updates; and
6. quarantine, decommissioning and deletion.

Device identity should be distinct from a human username. Mutual authentication using certificates or appropriately protected keys is preferable to shared passwords for large fleets. Registry permissions should follow least privilege: a temperature sensor should not be allowed to issue firmware commands to unrelated actuators.

3.2 Message brokers

A message broker accepts, buffers and distributes messages between producers and consumers. It decouples devices from applications, allowing each side to evolve independently. Common communication patterns include publish/subscribe, request/response and command queues.

In publish/subscribe, a producer publishes to a topic and subscribers receive messages according to topic permissions. MQTT is widely used in constrained IoT environments because it supports lightweight publish/subscribe communication and quality-of-service options. AMQP is often used where richer enterprise messaging, queues and routing are required. HTTP remains useful for APIs and occasional device interactions.

A broker design should address:

• topic naming and tenant isolation;
• message ordering requirements;
• retention and replay;
• maximum message size;
• delivery guarantees;
• authentication and authorisation;
• dead-letter handling; and
• monitoring of queue depth and delivery delay.

The broker is not a complete data platform. It transports messages; durable analytics and historical queries normally require a separate storage service.

3.3 Rules engines

A rules engine evaluates conditions and triggers actions. A rule may route a message to storage, create an alert, invoke a function or publish a command. Rules can be event-based, time-based or state-based.

For example, a rule might be expressed conceptually as:

“IF vibration exceeds the approved threshold for three consecutive readings, THEN create a maintenance event and reduce machine speed.”

Good rules include units, time windows, missing-data behaviour, hysteresis and an escalation policy. Hysteresis prevents rapid switching around a threshold. Safety-critical rules should be tested locally and should not depend solely on a cloud rules engine.

3.4 Serverless services

Serverless computing allows a provider to manage server allocation and execute functions in response to events. It is useful for intermittent workloads such as validating telemetry, enriching messages, generating notifications or processing device-registration events.

Advantages include rapid deployment, automatic scaling and payment based largely on use. Limitations include cold-start delay, execution-time limits, provider-specific interfaces, difficult local debugging and unpredictable cost at very high event volumes. Serverless functions are best for short, stateless operations. Long-running control loops, specialised hardware access and continuously running analytics may require containers or edge applications.

3.5 Containers

A container packages an application and its dependencies while sharing the host operating-system kernel. Containers support repeatable deployment across a developer workstation, edge node, fog cluster and cloud environment. They are useful for protocol adapters, stream processors, dashboards and machine-learning inference services.

Containers do not provide complete isolation equivalent to a separate physical computer. The host kernel, container runtime, image supply chain and orchestration system remain security concerns. Images should be minimal, signed, scanned for vulnerabilities and rebuilt regularly. Resource limits should prevent one workload from exhausting an edge node.

A comparison is shown below.

4. Storage and Data Management

No single storage technology is ideal for all IoT data.

• Time-series databases optimise measurements indexed by time and device.
• Relational databases support transactions, relationships and strong consistency.
• Object storage is economical for large files, raw video, logs and historical archives.
• Key-value stores provide fast lookup of device state and configuration.
• Stream-processing systems handle continuous events without first storing every message in a traditional database.

A practical design often uses a tiered approach. Recent data may remain on an edge node for rapid queries, operational data may be retained in a cloud time-series database, and raw files may be placed in object storage for a shorter or longer period according to value and regulation.

Retention should be based on purpose rather than indefinite accumulation. A data policy should state the retention period, owner, access rights, deletion method, backup treatment and legal basis. Metadata is essential: timestamp, source identity, unit, location, calibration status and quality flag make data interpretable.

5. Choosing Where Processing Occurs

A useful decision framework evaluates five dimensions:

The decision should also consider data gravity, regulatory requirements, skills, vendor lock-in and the consequences of failure. A hybrid design is often strongest: local safety and filtering, fog-level coordination, and cloud-level historical analytics.

Platform selection criteria

When comparing commercial or open-source platforms, evaluate:

1. Protocol support: MQTT, HTTP, CoAP, OPC UA, Modbus or other required interfaces.
2. Identity and security: certificate support, key rotation, role-based access and audit records.
3. Fleet management: provisioning, remote configuration, health monitoring and updates.
4. Edge capability: offline operation, local rules, container support and hardware acceleration.
5. Data services: broker scale, stream processing, databases, object storage and export options.
6. Reliability: availability objectives, backup, disaster recovery and regional redundancy.
7. Interoperability: open APIs, standard data formats and portability of workloads.
8. Economics: device fees, message charges, storage, data transfer, support and operational labour.
9. Governance: data location, compliance, auditability and contractual responsibilities.
10. Usability: documentation, diagnostic tools, developer experience and available skills.

A platform should be tested with representative message rates, offline periods, firmware updates, security incidents and failure recovery. A feature checklist alone is insufficient.

6. Applied Case: Cold-Chain Monitoring

The following is an illustrative case rather than a report of a particular company.

Background

A food distributor operates refrigerated trucks and warehouses. Temperature sensors report every 30 seconds. Regulations require evidence that products remained within an approved temperature range. A compressor failure can spoil a load within hours.

Problem

The original system sent every reading directly to a cloud dashboard. Cellular coverage was unreliable on some routes, alerts were delayed, and uploading all diagnostic data created unnecessary costs. Drivers sometimes received an alarm after the temperature had already become unsafe.

Analysis

The safety requirement is local and time-sensitive, while compliance reporting is central and historical. The system therefore needs separate flows. Sensor readings are small, but compressor vibration and diagnostic logs can be high volume. The design must also prevent unauthorised users from changing temperature thresholds.

Approach and solution

Each truck contains a gateway with a secure device identity. It receives sensor data over a local industrial network, validates timestamps and stores readings in a persistent queue. An edge rules service evaluates temperature using a configurable threshold and hysteresis. If the threshold is exceeded for a defined duration, the gateway activates a local alarm and sends a notification when connectivity is available.

The gateway publishes normal telemetry to a broker. A cloud rules engine routes the data to a time-series database and copies selected logs to object storage. A registry records the truck, sensors, firmware versions and certificate status. Fleet managers use a cloud application for reporting, while a fog service at each distribution region aggregates truck status and coordinates maintenance schedules.

Commands, such as changing a sampling interval, require an authorised cloud user, are signed, recorded in an audit log and applied only after the gateway validates the command. Firmware updates are staged and rolled back if health checks fail.

Outcome

The architecture preserves local alarms during cellular outages, reduces unnecessary transmission through aggregation, and provides central evidence for audits. It also creates a clearer boundary between safety control, operations and reporting.

Learning points

1. A cloud dashboard is not a substitute for local control.
2. Device identity and command authorisation are as important as telemetry transport.
3. Data reduction should occur near the source when raw data has limited immediate value.
4. Offline behaviour must be designed and tested, not assumed.
5. Storage, rules and registry services should have explicit ownership and retention policies.

7. Security, Governance and Ethical Issues

IoT platforms expand the attack surface from physical devices to cloud APIs. Important controls include secure boot, signed firmware, encrypted communication, certificate rotation, network segmentation, vulnerability management, least privilege, audit logging and incident response.

Privacy requires special care because sensors can infer occupancy, behaviour, health, location or work performance. Data minimisation means collecting only what is necessary. Pseudonymisation does not guarantee anonymity if multiple datasets can be linked. Organisations should define lawful purpose, access controls, retention and deletion procedures before deployment.

Safety and cybersecurity are connected. A compromised actuator may cause physical harm, while an over-restrictive security policy may prevent emergency maintenance. Critical systems should use defence in depth, manual override where appropriate, independent safety interlocks and tested recovery procedures.

Governance should assign responsibility for device ownership, data quality, model decisions, updates and incident response. Artificial-intelligence models deployed at the edge require version control, performance monitoring and examination for drift. A model that performs well in a laboratory may produce unsafe results after sensor ageing or environmental change.

8. Contemporary Developments and Best Practices

Current IoT platforms increasingly use lightweight Kubernetes distributions, confidential computing, digital twins, edge machine learning and software-defined networking. These technologies can improve portability and automation, but they also add operational complexity. A small deployment may be better served by a single hardened gateway than by a large orchestration stack.

Recommended practice is to:

• begin with explicit latency, reliability and data-governance requirements;
• keep safety functions independent of non-critical cloud services;
• use standard protocols and documented data schemas;
• make consumers idempotent when at-least-once delivery is used;
• monitor message delay, queue depth, device health and certificate expiry;
• design for secure provisioning and retirement from the beginning;
• test disconnection, duplication, clock errors, storage exhaustion and rollback;
• separate operational technology networks from general enterprise networks;
• measure total cost, including connectivity, support and skilled labour; and
• document which decisions occur at each layer and why.

Chapter Summary

Edge, fog and cloud platforms form a distributed computing continuum for IoT. Devices provide sensing and actuation, gateways connect local networks, edge nodes perform rapid local processing, fog services coordinate nearby sites, and cloud platforms provide elastic fleet-wide analytics and storage. Effective architecture assigns each workload to the location that best satisfies latency, connectivity, privacy, resilience, cost and maintenance requirements.

Device registries establish identity and lifecycle control. Message brokers decouple producers and consumers, while rules engines convert events into actions. Serverless functions suit short event-driven tasks; containers suit portable, continuously running workloads. Time-series databases, relational stores, key-value systems and object storage serve different data needs.

Professional IoT design must address duplicate delivery, offline operation, secure updates, data retention, privacy, safety and platform lock-in. A hybrid architecture, validated through realistic failure and performance testing, is frequently more robust than a purely edge or purely cloud design.

Key Terms

Device registry: An authoritative inventory containing device identities, attributes and lifecycle information.

Edge computing: Processing performed close to the devices producing data.

Fog computing: Distributed coordination and computing between edge sites and central cloud services.

Cloud computing: Elastic, centrally managed computing and storage delivered through data-centre infrastructure.

Gateway: A node that connects local devices to other networks and often translates protocols.

Message broker: Software that accepts, buffers and routes messages between producers and consumers.

Publish/subscribe: A communication pattern in which publishers send messages to topics and subscribers receive selected topics.

Rules engine: A service that evaluates conditions and triggers actions.

Serverless computing: Event-driven execution in which infrastructure provisioning is managed by a provider.

Container: A packaged application environment sharing the host operating-system kernel.

Time-series database: A database optimised for data indexed by time.

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

At-least-once delivery: Delivery semantics in which a message is delivered one or more times.

Idempotence: The property that repeating an operation produces the same final effect.

Digital twin: A software representation of a physical asset, process or environment.

Data minimisation: Collecting and retaining no more personal or operational data than necessary.

Hysteresis: Separate thresholds for switching on and switching off to prevent rapid oscillation.

Fleet management: Provisioning, monitoring, updating and retiring many devices.

Review Questions

Short Answer Questions

1. What are the main responsibilities of an IoT gateway?
2. Why should a safety-critical control action normally be performed locally?
3. What information is commonly held in a device registry?
4. How does a message broker decouple IoT producers and consumers?
5. State one advantage and one limitation of serverless computing.

Long Answer Questions

1. Explain the differences among edge, fog and cloud computing, using an industrial example.
2. Describe a complete telemetry flow from a sensor to a cloud application and identify the role of each platform service.
3. Compare containers, serverless functions and virtual machines for IoT workloads.
4. Explain how storage technologies can be combined in a tiered IoT data architecture.
5. Discuss the security and privacy controls required for a large device fleet.

Analytical / Application Questions

1. A remote water-treatment station must continue controlling pumps during a 12-hour network outage. Design an edge, fog and cloud data flow and justify where each decision occurs.
2. An organisation wants to upload high-rate camera and vibration data from 2,000 machines. Analyse the bandwidth, privacy and cost implications and propose a filtering and storage strategy.
3. Evaluate two hypothetical IoT platforms: Platform A offers strong cloud analytics but weak offline support; Platform B offers local containers and protocol integration but fewer managed databases. Recommend a platform for a safety-sensitive factory and state the conditions that could change your decision.

Multiple Choice Questions with Answers

Question 1

Which layer is normally most suitable for a millisecond-level safety response?

A. Cloud data warehouse

B. Local device or edge node

C. Long-term object storage

D. Enterprise reporting application

Correct Answer: B. Local device or edge node

Question 2

What is the primary purpose of an IoT device registry?

A. To compress all sensor measurements

B. To provide video rendering

C. To manage device identity, attributes and lifecycle

D. To replace every message broker

Correct Answer: C. To manage device identity, attributes and lifecycle

Question 3

Which service primarily decouples message producers from consumers?

A. Message broker

B. Time-series database

C. Firmware compiler

D. Identity directory for employees

Correct Answer: A. Message broker

Question 4

A system uses at-least-once delivery. What design property helps prevent duplicate effects?

A. Idempotence

B. Higher screen resolution

C. Longer topic names

D. Disabling timestamps

Correct Answer: A. Idempotence

Question 5

Which workload is generally most appropriate for a serverless function?

A. A permanent motor-control loop with strict timing

B. A short event-driven telemetry transformation

C. A complete operating system for a gateway

D. A physical safety interlock

Correct Answer: B. A short event-driven telemetry transformation

Question 6

What is a major advantage of edge processing?

A. It guarantees unlimited storage

B. It eliminates all security risks

C. It can reduce latency and upstream bandwidth use

D. It removes the need for device identity

Correct Answer: C. It can reduce latency and upstream bandwidth use

Question 7

Which storage type is generally suited to large raw video archives?

A. Object storage

B. CPU register storage

C. A topic subscription alone

D. A device certificate

Correct Answer: A. Object storage

Question 8

Five hundred sensors each send 10 samples per second with a 16-byte payload. Ignoring overhead, what is the data rate?

A. 64 kbit/s

B. 640 kbit/s

C. 6.4 Mbit/s

D. 64 Mbit/s

Correct Answer: B. 640 kbit/s

Question 9

Why is hysteresis useful in an IoT rules engine?

A. It prevents rapid switching around a threshold

B. It encrypts every message automatically

C. It increases sensor sampling frequency

D. It replaces certificate rotation

Correct Answer: A. It prevents rapid switching around a threshold

Question 10

Which consideration most strongly favours cloud processing over edge processing?

A. A control action must occur within milliseconds

B. The site frequently loses connectivity

C. Fleet-wide historical analytics is required

D. Sensitive raw data must never leave the site

Correct Answer: C. Fleet-wide historical analytics is required