Edge & Fog Computing · Study deck

Edge, Fog, and Cloud: Device Integration

A freezer probe is replaced with a newer board that reports temperature in hundredths of a degree.

Edge Eddie is your guide for this deck.

clouddevicesintegration

Edge Eddie, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Select device classes based on task ownership, power source, runtime needs, interfaces, and lifecycle support.
Draw an integration path from sensor or actuator interface through fog adapter to cloud service.
Define gateway contracts for protocol translation, record normalization, command validation, buffering, and replay.
Explain how identity, provisioning, certificates, updates, and health reporting cross edge, fog, and cloud tiers.

Major section

In 60 Seconds · Start Simple

The cloud can hold the fleet history later.

The local path must keep the food safe now.
A gateway is a device or service that joins field devices to a wider network.
The word protocol means an agreed set of rules for how devices exchange data.
Those details can change the tier boundary.

Major section

Minimum Viable Understanding · Most Valuable Understanding

Device class follows responsibility.: Use constrained devices for sensing and local action, gateway-class nodes for protocol adaptation and local coordination, and cloud services for fleet records, policy, analytics, and rollout control.

Integration boundaries need contracts.: Drivers, adapters, normalized records, commands, certificates, health signals, and update packages each need an owner and version.
Gateways are not just pipes.: A fog gateway usually validates identity, translates protocols, normalizes payloads, buffers during outages, applies site policy, and reports local health.
Management traffic matters.: Provisioning, configuration, certificates, firmware, model files, logs, and rollback signals must be designed alongside telemetry.

Major section

Device Integration Map

A device integration plan should show what happens before the cloud sees a record and what happens before a device obeys a command.

Owns fleet identity, long-term records, dashboards, analytics, rollout policy, audit trails, and cross-site coordination.

Edge-fog-cloud integration across three tiers: edge devices, neighborhood fog hubs for low-latency coordination, and cloud data centers for fleet-wide training and analytics.

Major section

Device Class Selection · Interfaces and Drivers

Typical constraints are small memory, limited storage, tight power budget, and simple network stacks.

It usually has persistent storage and a managed runtime.
It should not own time-critical physical safety decisions.
An impossible reading should be rejected or flagged before it becomes operational evidence.
The link choice defines pairing, addressing, retries, security, and diagnostics.

Major section

Gateway Contract

The gateway contract is the most important maintainability boundary in many edge-fog-cloud systems.

It lets device protocols change without forcing cloud applications to change.
The gateway is maintainable only if both sides of its translation boundary have an explicit contract.
Those labelled hand-offs define exactly what a gateway implementation and its tests must own.

Gateway contract from device signal to normalized cloud record

Major section

Gateway Contract (continued)

The Local queue then preserves event time and message ID before the Cloud API applies its schema and acknowledgement.

That record lets a reviewer distinguish a sensor fault from an adapter, queue, API, or command-validation failure.
Parse: Decode device-specific frames, validate checksums or signatures, and reject malformed records.
A useful gateway contract is bidirectional.

Major section

Identity and Provisioning · Store-and-Forward

Every integrated device needs a trustworthy lifecycle record.

The record should connect a physical asset to credentials, firmware, calibration, adapter compatibility, ownership, and retirement status.
A field device should not hold cloud-wide privileges.
A gateway should not accept commands for devices outside its assigned scope.
Outages are normal in edge deployments.

Major section

Integration Patterns · Update and Management Paths

Many simple devices send regular readings to a local gateway.

The gateway validates, normalizes, summarizes, and forwards records.
The device performs local detection, filtering, or control and sends events or compact evidence.
A local gateway or site server runs models, rules, or correlation across several devices.

Major section

Replace the Freezer Probe without Rewriting the Fleet Service

Its normalized reading is 42 × 0.1 °C = 4.2 °C.

The replacement reports 420 with scale 0.01 °C per count, which also gives 4.2 °C.
The driver identifies the hardware and payload version; the gateway adapter applies the matching scale.
A local alarm still acts on current readings.

Major section

Replace the Freezer Probe without Rewriting the Fleet Service (continued)

The cloud consumes the stable value and unit while retaining enough version evidence to explain the conversion.

With one record at each minute's end, the queue receives 15 records.
At an illustrative 96 bytes per normalized record, this is 1,440 bytes before filesystem overhead.
Commands need the reverse discipline.

Major section

Replace the Freezer Probe without Rewriting the Fleet Service (continued)

Queueing preserves history for later replay; it must not become a dependency of the immediate alarm path.

The freezer uses the same responsibility split, with a different time requirement.
The adapter should flag or quarantine it instead of applying the old scale by default.
Stable message identities should let the receiving service avoid duplicate history while preserving the original event times.

Major section

Summary · Key Takeaway

Device integration connects physical interfaces, gateway adapters, and cloud services through explicit contracts.

Identity, provisioning, version evidence, updates, rollback, quarantine, and retirement are part of the integration design.
Device integration succeeds when identity, protocol translation, schemas, command paths, updates, and telemetry are designed together.
A working data path is not enough without secure management and observable failure handling.

Deck summary

Key takeaways

The cloud can hold the fleet history later.

Device class follows responsibility.: Use constrained devices for sensing and local action, gateway-class nodes for protocol adaptation and local coordination, and cloud services for fleet records, policy, analytics, and rollout control.
A device integration plan should show what happens before the cloud sees a record and what happens before a device obeys a command.
Typical constraints are small memory, limited storage, tight power budget, and simple network stacks.
The gateway contract is the most important maintainability boundary in many edge-fog-cloud systems.

Retrieval practice

Recall check 1 of 5

Edge Eddie says: answer from memory, then check your reasoning.

Q1A gateway receives fieldbus frames, verifies the device identity, converts each payload into a cloud-facing JSON record, and stores records while the WAN link is down. What integration role is it performing?

ACloud analytics, because preparing records for later dashboards is the same as running the fleet analytics service.

BFog adapter, because it translates protocols, normalizes records, validates identity, and buffers data for the site

CPure edge sensing, because records started at physical sensors and no gateway contract is needed after sampling.

DNo integration role, because only the cloud can integrate devices once a fieldbus frame has been received.

Show answer

Answer: B Those are gateway or fog-adapter responsibilities that sit between device-specific protocols and cloud-facing contracts.

Retrieval practice

Recall check 2 of 5

Edge Eddie says: answer from memory, then check your reasoning.

Q2A battery-powered field node wakes, samples one physical measurement, checks a local threshold, stores a recent reading, and reports through a nearby gateway. Which class is the best starting point?

AConstrained edge device, because the task is simple, local, and power-sensitive

BGateway-class node, because a richer runtime would simplify protocol integration and remote diagnostics

CCloud service, because cloud services are easier to update

DAccelerated gateway, because future analytics might be needed

Show answer

Answer: A The node owns sensing and simple local validation.

Retrieval practice

Recall check 3 of 5

Edge Eddie says: answer from memory, then check your reasoning.

Q3A gateway maps a Modbus register with raw value 214 and documented scale 0.1 C to JSON as {"value": 214}. What is wrong?

AThe raw value is acceptable because the dashboard can apply the device's register map when plotting the temperature.

BIt forwarded the raw register and lost scale, units, identity, and event time; the gateway should publish 21.4 C with metadata.

CThe JSON syntax is invalid, so the platform cannot parse the record, store it in a database, or display it in a dashboard.

DUse an XML schema for the register value so type validation can establish the physical meaning before storage.

Show answer

Answer: B Translation must preserve physical meaning, not only produce valid-looking JSON.

Retrieval practice

Recall check 4 of 5

Edge Eddie says: answer from memory, then check your reasoning.

Q4A site gateway loses WAN connectivity. Devices continue operating and the gateway stores normalized records locally. What must each queued record include so replay is safe when connectivity returns?

AA stable message identifier, event timestamp, device identity, schema version, and quality state

BThe newest reading and device identity, replacing older queued values to reduce recovery traffic

COnly the cloud receive time, because replayed records arrive together

DOnly the gateway name, because the gateway can infer everything else later

Show answer

Answer: A Those fields allow ordering, deduplication, late-arrival handling, and interpretation after replay.

Retrieval practice

Recall check 5 of 5

Edge Eddie says: answer from memory, then check your reasoning.

Q5Place each integration responsibility where it lives so you can keep records trustworthy through device replacement, gateway outage, and cloud recovery.

AEdge device

BCloud dashboard

CFleet registry

DLong-term archive

Show answer

Answer: A The edge device owns physical signals, the fog adapter and queue normalize and preserve records, and the cloud registry governs fleet identity so you can trace responsibility through failures.

Q6Complete the gateway gate that decides whether a device record is safe to forward:

Aif not device.get('enrolled'):

Bif record.get('value'):

Cif device.get('cloud_only'):

Dif True:

Show answer

Answer: A A gateway should reject unenrolled devices, quarantine unexpected schemas, and require message identifiers plus event time before forwarding records upstream.

Print reference

Answers 1 of 2

Answer key.

B · Those are gateway or fog-adapter responsibilities that sit between device-specific protocols and cloud-facing contracts.
A · The node owns sensing and simple local validation.
B · Translation must preserve physical meaning, not only produce valid-looking JSON.
A · Those fields allow ordering, deduplication, late-arrival handling, and interpretation after replay.
A · The edge device owns physical signals, the fog adapter and queue normalize and preserve records, and the cloud registry governs fleet identity so you can trace responsibility through failures.

Print reference

Answers 2 of 2

Answer key.

A · A gateway should reject unenrolled devices, quarantine unexpected schemas, and require message identifiers plus event time before forwarding records upstream.