Chapters

 Edge and Fog Computing Module Guide

Edge Eddie, your edge computing guide

Your guide: Edge Eddie

“Send the decision, not the raw feed — the edge earns its keep in milliseconds and megabytes saved.”

Start With the Module

This guide maps the current learning path for Edge Fog. The module contains 20 chapters, linked below in the order learners can study them.

Follow Edge Eddie as a battery gateway chooses local, nearby, or cloud work from one measured workload budget.

  1. Edge Eddie stands by a gateway with paths to itself, a nearby node, and a cloud.

    This battery gateway has three places to work.

  2. Eddie measures the same workload at each of the three places.

    Measure time and energy for this one job.

  3. Eddie compares one job budget and selects a feasible place.

    Pick the place that meets this job's needs.

  4. Load, battery, heat, and network symbols change, so Eddie reopens the record.

    Test again when the conditions change.

A battery gateway chooses local, nearby, or cloud work from one measured workload budget.

Chapters by Part

Edge-Fog Basics

Edge-Cloud Integration

The Edge–Cloud Integration chapters continue the same workload record. After placement and architecture are clear, carry the normal and degraded paths, contracts, owners, and field evidence into device integration and operating at scale.

Wide Edge–Fog–Cloud chapter router drawn over three horizontal tier bands: Edge and device, Fog and site, and Cloud and fleet. Four review lenses apply to the same workload record. Place assigns workload responsibilities and fallback across the tiers. Architect maps telemetry, command, management, and health paths across timing, trust, authority, version, and failure boundaries. Integrate defines device and gateway identity, schema, buffering, replay, update, rollback, and command-validation contracts. Operate records state authority, failover, observability, lifecycle, recovery, governance, and retest evidence. A bottom ribbon carries the review record forward, while a dashed return shows that field evidence can reopen any earlier lens.
One workload is placed across Edge, Fog, and Cloud; its paths and authority boundaries are mapped; device and gateway contracts make those paths implementable; and operating evidence at scale can reopen any earlier decision.

The Three Tiers and Architecture now open the book. Continue here with Device Integration when identity, schemas, buffering, replay, updates, rollback, or command validation are missing. Open Operating at Scale when state authority, failover, observability, lifecycle, recovery, or governance evidence is the unresolved question.

Edge AI & ML

The six Edge AI chapters are not six deployment stages. They are review lenses that answer different questions. Follow the numbered order when the subject is new; during design or troubleshooting, reopen the lens whose evidence is missing and expect model, runtime, target, and field constraints to affect one another.

Wide Edge AI chapter router. Fundamentals is the entry lens for why, placement, and fallback. TinyML, Optimization, and Hardware form an iterative target-fit system around the sensor path, model, runtime, and hardware. Applications forms the field-fit and operations boundary and sends drift, failure, or changed requirements back to earlier review lenses. A separate dashed Lab lane is labelled simulated evidence practice and not deployment proof. Numbered badges show the recommended first-study order rather than a compulsory production sequence.
Use the numbers as a first-study route, not as a compulsory production pipeline. Fundamentals establishes placement and fallback; TinyML, Optimization, and Hardware form an iterative target-fit review; Applications owns use-case fit and field operation; and the Lab practises the evidence method without proving production readiness.

Start with Fundamentals unless the local decision, placement, and fallback are already justified. Use TinyML for MCU-fit questions, Optimization for measured model-budget failures, Hardware for target and runtime fit, and Applications for target validation, rollout, monitoring, drift, rollback, and human review. Use the Lab to practise the method, then repeat its measurements on the intended sensor path and hardware before making a release claim.

Fog Architecture

Fog Production

Design Trade-off Scenarios

Choose a Starting Point

If this subject is new, follow the parts and chapters in the order shown above. If you already have a specific design or troubleshooting question, use the relevant part heading and open the direct chapter link whose title matches that question.

Use the sidebar and site search for supporting material; use this chapter map as your main route through the module.

How to Use This Material

  • Start with the first chapter in the relevant part when the topic is unfamiliar.
  • Use direct chapter links for study plans, lab preparation, and review evidence.

← Back to All Modules