14 Edge AI: Application Fit and Constraints

edge-fog

14.1 Start With the Decision

An edge model earns its place only when local action beats cloud delay or exposure. Each use case must show that fit and its cost.

14.2 Route Overview

This is part 1 of 2. Continue with Edge AI: Deployment Validation and Runtime Design.

14.3 Part Objectives

Compare edge AI application families and constraints.
Choose local inference from latency, privacy, and energy needs.

In 60 Seconds

Bandwidth is how much data a link can carry. Latency is the time a result takes to arrive.

Edge AI is useful when the decision is more valuable near the sensor than in a remote cloud call. Good applications need local latency, offline continuity, privacy control, bandwidth reduction, or site-level autonomy. The deployment pipeline starts with a narrow operational decision, then validates data quality, trains a baseline model, compresses and converts the model, tests it on the real target device, deploys with rollback, and monitors drift after release. Do not sell edge AI with generic financial numbers; prove value with the specific workflow, failure cost, human review path, and measured target-device behavior.

Phoebe’s Field Notes: Two Different Things Called “Quantization”

The mathematical gist. A 30 fps camera has a 15.0 Hz Nyquist limit, so a 22.0 Hz vibration can appear as a false 8.00 Hz wobble. A catalog-typical 10-bit pixel ADC adds a separate $0.0977\%$ full-scale step, $0.0282\%$ RMS ideal floor, and 62.0 dB ideal ceiling. Frame rate protects motion identity; ADC depth protects brightness detail; later model quantisation repairs neither.

14.4 Start Simple

Picture a camera that must stop a machine when it sees a bad part. Waiting for a far service may take too long or fail when the link is down.

First, name the local choice and how soon it must be made. Then state what data may leave the site and what proof must come back.

Local work can cut delay and data use, but it spends device power and is harder to update. Remote work is easier to share, yet it depends on the link.

That is the simple story, but it cannot place every model or control step. The cases and checks later in the chapter set those bounds.

Use the Practitioner sections to test a local task and its handoff. Use the Under the Hood sections to study model change, resource limits, and weak links in more depth.

Bandwidth is how much data a link can carry. Latency is the time a result takes to arrive.

Plain check

Name the local event. Name the local choice. Mark the time limit. Mark the safe state.
Check the input source. Check its age. Check its quality. Stop on weak data.
Run the local model. Save its build. Save its score. Save the chosen action.
Test no wide link. Test a slow link. Test lost power. Test a full store.
Keep raw data small. Keep its life short. Send only needed proof. Mark who may read it.
Check device heat. Check free memory. Check free space. Check the power cost.
Set a safe fallback. Make it easy to see. Make it easy to test. Give it an owner.
Send a clear summary. Keep local time with it. Keep model build with it. Keep result with it.
Test a new room. Test a new sound. Test a new camera. Reopen the model claim.
Plan safe updates. Keep the old build. Check the new build. Make return possible.
Use Practitioner to trial. Use deeper resource checks. Test the handoff. State each bound.
Review field logs. Find slow drift. Find new cases. Set the next test.

Choose one operational decision where a nearby prediction changes what the system can do. The core idea is that edge AI is valuable only when local action, privacy, bandwidth, offline continuity, or site autonomy improves the workflow. Everyday IoT application design starts with the failure cost and the human review path, then adds data, model, conversion, deployment, rollback, and drift monitoring. Build one application story before claiming broad value.

Minimum Viable Understanding

Edge AI is an inference placement choice. Training usually stays in the cloud or workstation; inference runs near the data source.
The application drives the hardware. A wake-word detector, a vibration monitor, and a multi-camera inspection line need different sensors, accelerators, memory, power, and update processes.
Target-device validation is mandatory. Accuracy measured in a notebook is not enough; validate latency, memory, thermal behavior, power, and failure mode on the deployed device class.
Monitoring continues after deployment. Edge models can drift when lighting, equipment, firmware, placement, or user behavior changes.
The cloud still matters. It stores fleet metadata, collects evidence, manages models, coordinates updates, and supports retraining.

14.5 Learning Objectives

By the end of this chapter, you will be able to:

Select edge AI application candidates from latency, privacy, bandwidth, autonomy, and operational-value evidence.
Compare visual inspection, predictive maintenance, audio/event detection, and privacy-preserving sensing patterns.
Design an edge AI deployment loop from data collection through monitoring and retraining.
Identify target-device validation requirements for model size, memory, latency, power, and fallback behavior.
Explain how model updates, rollback, drift monitoring, and human review fit into a production edge AI system.
Build a short edge AI application decision record that avoids generic financial claims.

Chapter Roadmap

In 60 Seconds
Phoebe’s Field Notes: Two Different Things Called “Quantization”
Start Simple
Minimum Viable Understanding
Most Valuable Understanding
Prerequisites
Application Map
Knowledge Check: Application Fit
When Edge AI Is a Good Fit
Avoid Generic Value Claims
Checkpoint: Fit Evidence
Application Family 1: Visual Inspection
Application Family 2: Predictive Maintenance
Knowledge Check: Maintenance Evidence
Application Family 3: Audio and Event Detection
Application Family 4: Privacy-Preserving Sensing
Knowledge Check: Privacy-Preserving Edge AI
Checkpoint: Application Family

Most Valuable Understanding

Edge AI should not be justified by “AI on device” as a novelty. It is justified when a local decision changes the outcome: a defect is rejected before it ships, a motor is inspected before it fails, private media stays local, a wake event is filtered before the main processor wakes, or a site keeps operating during poor connectivity.

14.6 Prerequisites

Edge AI Fundamentals: Review why inference sometimes belongs near the sensor.
Edge AI Hardware: Understand target classes from microcontrollers to accelerator-equipped gateways.
Edge AI Optimization: Review quantization, pruning, and conversion constraints.
TinyML on Microcontrollers: Understand small-model deployment on constrained devices.
SOA Resilience Patterns: Connect local inference with fallback, monitoring, and safe degradation.

14.7 Application Map

Edge AI applications are easier to reason about when you separate the sensing path, local inference path, action path, and cloud evidence path.

Inspect Figure 14.1 before continuing. A list of edge-AI domains does not yet explain what the device actually does. Figure 14.1 is worth examining because it separates the common sensing-and-inference path from the application-specific decision that follows.

Figure 14.1: An edge AI application map showing sensor input, local inference, edge action, application families, and cloud insight

In the diagram Figure 14.1, begin with Sensor, where camera, audio, and vibration enter the system, then move into Local inference and its filter, classify, detect, and score operations. The path branches at Action into outcomes such as Inspection, Maintenance, Audio, and Privacy, while only insight, evidence, and model health move to the cloud. That split is the reusable application pattern: raw observations support a local response, and compact evidence supports later fleet review.

14.7.1 Local Decision

The device or gateway classifies, detects, scores, or filters data before sending anything upstream.

14.7.2 Local Action

The edge system raises an alert, rejects an item, wakes a larger processor, changes a control mode, or stores evidence for human review.

14.7.3 Cloud Evidence

The cloud receives compact results, examples for review, model health, fleet metadata, and enough evidence to improve the model.

14.7.4 Update Loop

Models, thresholds, labels, and fallback policy are updated through a controlled deployment process, not copied manually to devices.

Knowledge Check: Application Fit

14.8 When Edge AI Is a Good Fit

Use edge AI when at least one of these conditions is true and measurable.

14.8.1 Latency Is Operational

The decision must happen before a conveyor, vehicle, operator, process, or device state changes.

14.8.2 Connectivity Is Not Guaranteed

The site must keep filtering, detecting, or protecting equipment when cloud connectivity is delayed or unavailable.

14.8.3 Raw Data Is Sensitive

Images, audio, health signals, location, or occupancy data should be minimized before it leaves the device or site.

14.8.4 Bandwidth Is a Constraint

The raw stream is large, frequent, or expensive to transmit, but the useful result is small.

14.8.5 Human Attention Is Scarce

The model can triage events, rank evidence, or reduce the volume of manual review without hiding uncertainty.

14.8.6 Local Control Needs Guardrails

The edge device can apply a low-risk decision locally and escalate high-risk cases to cloud or human review.

Avoid Generic Value Claims

Do not copy payback periods, labor-replacement numbers, or savings estimates from another setting. Edge AI value depends on the specific process, baseline cost, defect cost, false positive cost, missed detection cost, installation work, retraining cost, and review workflow.

Checkpoint: Fit Evidence

You now know:

Edge AI needs at least one measurable fit condition: latency, connectivity, raw-data sensitivity, bandwidth, human attention, or guarded local control.
A good candidate turns nearby sensor data into a local decision, local action, compact cloud evidence, and a controlled update loop.
Generic value claims are not evidence; the application record must name the local action, false-positive cost, missed-detection cost, and review path.

With fit evidence bounded, the next question is which application family carries the strongest operational case.

14.9 Application Family 1: Visual Inspection

Visual inspection is a strong edge AI candidate when image volume is high and the action needs to happen near the line, station, vehicle, or gate.

14.9.1 Useful Decisions

Presence or absence, product orientation, surface defect, packaging mismatch, count mismatch, object class, safety-zone occupancy, and visible quality drift.

14.9.2 Target Evidence

Representative lighting, camera placement, lens choice, motion blur, acceptable defect definitions, rejection workflow, and examples of near-miss cases.

14.9.3 Failure Cost

False rejects can waste product or slow production. Missed defects can reach customers or downstream processes. Both costs must be included.

14.9.4 Deployment Pattern

Run this deployment pattern as an evidence loop. First capture and preprocess the image near the camera, then infer and apply the bounded local indicator or reject action. Record latency and the action result before uploading a sampled, policy-approved example for review. The cloud copy supports monitoring and retraining; it is not a substitute for proving the local path. This order connects immediate inspection behavior to the chapter’s wider lifecycle of target validation, staged rollout, drift review, and model replacement.

For visual inspection, benchmark the full pipeline, not only model inference. Camera exposure, preprocessing, data transfer, postprocessing, actuator timing, and human review can dominate the real decision time.

14.10 Application Family 2: Predictive Maintenance

Predictive maintenance works best when the edge model catches a local pattern that is costly to stream continuously and meaningful to maintenance teams.

14.10.1 Useful Signals

Vibration, acoustic emission, current draw, temperature, pressure, flow, torque, duty cycle, and event counters.

14.10.2 Useful Decisions

Normal, watch, inspect soon, stop safely, schedule service, collect high-resolution evidence, or escalate to expert review.

14.10.3 Data Risk

Failure examples are often rare. A model trained only on normal operation may need anomaly detection, expert labels, and careful alert thresholds.

14.10.4 Deployment Pattern

Extract features locally, run a compact model, store short evidence windows around alerts, and send trend summaries to the cloud.

Knowledge Check: Maintenance Evidence

14.11 Application Family 3: Audio and Event Detection

Audio edge AI often uses a staged pipeline: a small always-on detector decides whether to wake a larger model, processor, radio, or application.

14.11.1 Useful Decisions

Wake word, alarm sound, machine sound change, glass break, occupancy cue, animal call, safety event, or abnormal operating noise.

14.11.2 Privacy Benefit

The device can avoid streaming raw audio by sending event metadata, confidence, short redacted snippets, or no audio at all.

14.11.3 Review Trap

Wake-word examples, accents, background noise, room acoustics, and microphone placement can change performance after deployment.

14.11.4 Deployment Pattern

Use a low-power first stage, a stronger verification stage when needed, and a cloud loop for false-positive and missed-event review.

14.12 Application Family 4: Privacy-Preserving Sensing

Some applications are primarily about reducing raw data exposure rather than controlling a machine.

14.12.1 Examples

Occupancy without identity, activity recognition without raw video upload, local face redaction, local license-plate redaction, and health signal summarization.

14.12.2 Design Question

What is the minimum information the cloud needs to deliver the service, diagnose failures, and improve the model?

14.12.3 Governance Risk

Local inference does not automatically make a system privacy-preserving. Logs, samples, labels, and update data can still leak sensitive information.

14.12.4 Deployment Pattern

Treat privacy-preserving deployment as a data-boundary decision, not simply as local inference. Start with raw sensor data held at the edge, derive the minimum result needed by the remote service, and send only that compact result by default. Then document which exceptional samples may be retained or uploaded, for what purpose, under which access and retention controls, and how consent or policy is enforced. This pattern connects the local model to the chapter’s operating loop: monitor useful outcomes without quietly rebuilding the sensitive data stream that edge placement was meant to avoid.

Knowledge Check: Privacy-Preserving Edge AI

Checkpoint: Application Family

You now know:

The chapter compares four families: visual inspection, predictive maintenance, audio and event detection, and privacy-preserving sensing.
Each family needs its own evidence: lighting and rejection workflow, rare failure labels, wake-stage behavior, or upload and retention policy.
Local inference reduces raw streaming, but it does not remove the need for sampled evidence, operator review, governance, and retraining data.

Once the family is clear, the work shifts from use-case selection to the release loop that keeps the model controlled after export.

14.13 Continue to the Next Part

Carry this evidence into Edge AI: Deployment Validation and Runtime Design, which begins with Deployment Pipeline.