Edge AI, TinyML and Distributed Intelligence

Introduction and Context

The Internet of Things (IoT) connects sensors, actuators, embedded devices, gateways, networks and cloud services. Traditional IoT analytics often sends sensor data to a remote cloud platform, where computationally intensive machine-learning models are trained and executed. This architecture is powerful, but it can be unsuitable when applications require very low latency, continuous operation during network failure, protection of sensitive data, or low communication cost.

Edge AI addresses this problem by executing artificial-intelligence workloads close to where data is generated. The edge may be a sensor node, microcontroller, industrial gateway, smartphone, vehicle computer or local server. TinyML is the specialized application of machine learning on highly constrained devices, especially microcontrollers with limited memory, processing power and energy. Distributed intelligence extends these ideas across multiple cooperating devices and cloud services rather than concentrating all intelligence in one location.

The central engineering challenge is not simply to run a model on a smaller computer. It is to design an end-to-end system that satisfies accuracy, latency, memory, energy, privacy, reliability, maintainability and cost requirements simultaneously.

Learning Objectives

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

1. Explain edge AI, TinyML and distributed intelligence and distinguish their roles in an IoT architecture.

2. Identify suitable locations for training, inference, storage and control in cloud–edge systems.

3. Apply quantization, pruning, knowledge distillation and architecture selection to reduce model resource requirements.

4. Estimate memory, latency, communication and energy implications of an edge-AI design.

5. Compare microcontrollers, gateways, CPUs, GPUs, NPUs and other accelerators for deployment.

6. Evaluate privacy, reliability, security and governance issues in on-device and federated learning.

7. Design and assess an end-to-end edge-AI solution using appropriate performance metrics.

1. From Cloud-Centric IoT to Distributed Intelligence

A cloud-centric system usually follows this sequence: sensors collect data, a network transports it, cloud infrastructure performs inference or analytics, and a decision is returned to an actuator or user. This arrangement supports centralized model management and large-scale computation. However, the round-trip delay may be unacceptable for collision avoidance, machine protection or closed-loop control. Continuous transmission also consumes energy and bandwidth and may expose personal or industrial information.

An edge-oriented architecture distributes functions across several layers:

• Device or far edge: sensors, actuators and microcontrollers perform signal processing, event detection and sometimes inference.
• Near edge or gateway: an industrial computer, router or local server aggregates devices, performs larger inference tasks, manages protocols and provides temporary storage.
• Cloud or central platform: model training, fleet-wide analysis, long-term storage, digital-twin processing and global management are commonly performed here.

These layers are not rigid. A camera may run object detection on an edge accelerator, while a microcontroller performs wake-word detection and the cloud conducts periodic retraining. The correct division depends on application requirements rather than on a universal rule.

Edge AI and TinyML

Edge AI is an architectural and computational concept: AI is executed near the data source. TinyML is a more restrictive engineering domain involving models deployed on devices such as Cortex-M microcontrollers, digital signal processors and similarly constrained processors. TinyML systems commonly operate with kilobytes or a few megabytes of RAM and flash, limited clock speed, and strict energy budgets. They often use integer arithmetic and event-driven operation.

A gateway with a multicore processor and several gigabytes of memory can run a compressed vision model but is not normally described as a TinyML device. Conversely, a microcontroller performing keyword spotting from a microphone is a typical TinyML application.

Why Distributed Intelligence Matters

Distributed intelligence can improve:

• Latency: local decisions avoid network round trips.
• Availability: devices can continue operating during intermittent connectivity.
• Privacy: raw audio, video or biometric data may remain local.
• Scalability: only events, features or summaries need to be transmitted.
• Energy efficiency: communication is often more expensive than local computation.
• Context awareness: devices can respond to local conditions immediately.

The disadvantages include heterogeneous hardware, difficult debugging, model-version inconsistency, limited local observability and a larger attack surface. A distributed system therefore requires explicit coordination, security and lifecycle management.

2. The Cloud–Edge Partitioning Decision

The partitioning problem asks where each function should execute. The functions may include sensing, filtering, feature extraction, inference, data storage, training, explanation, actuation and monitoring.

A useful decision process is:

1. Define the control-loop deadline and required reliability.

2. Classify the data according to sensitivity and regulatory obligations.

3. Estimate computational, memory and energy resources at each layer.

4. Estimate communication volume, network reliability and operating cost.

5. Decide which outputs must be immediate and which can be delayed.

6. Select a partition and test it under realistic workload and environmental conditions.

Latency Model

For an inference request sent from a device to a cloud service, a simplified end-to-end latency model is

\[

T_{total}=T_{sense}+T_{pre}+T_{up}+T_{queue}+T_{infer}+T_{down}+T_{post},

\]

where the terms represent sensing, preprocessing, upload, queueing, remote inference, download and postprocessing times. The expression is an engineering decomposition, not a physical law. It assumes the stages are sequential for the request; in a pipelined system some terms may overlap.

For local inference, upload and download may disappear, giving approximately

\[

T_{local}=T_{sense}+T_{pre}+T_{infer,local}+T_{post}.

\]

A local design is preferable for a hard deadline when its worst-case latency, not merely its average latency, remains below the deadline. Network jitter and cloud queueing make average cloud latency an inadequate safety guarantee.

Communication and Energy

If a device transmits \(N\) bits and the radio consumes \(E_b\) joules per transmitted bit, the approximate transmission energy is

\[

E_{tx}=N E_b.

\]

This estimate excludes startup, reception, protocol and retransmission costs. It is therefore useful for comparison but not for final battery certification. Sending a compact event or feature vector can consume substantially less energy than transmitting continuous raw sensor data.

A broader device energy budget can be represented as

\[

E_{total}=E_{sense}+E_{compute}+E_{tx}+E_{rx}+E_{idle},

\]

provided the terms are measured over the same time interval. Duty cycling, wake-on-event sensing and batching can reduce average energy, although batching may increase latency.

Partitioning Patterns

Common patterns include:

• Cloud-only inference: simple devices transmit data; useful when connectivity is reliable and privacy constraints are low.
• Edge-only inference: the gateway makes decisions locally and sends summaries to the cloud.
• Split inference: early model layers execute on a device and later layers on a gateway or cloud. The intermediate representation must be smaller and sufficiently useful to justify the design.
• Hierarchical inference: a small model handles ordinary cases while a larger model is invoked for uncertain cases.
• Collaborative sensing: multiple devices share local features or decisions rather than raw data.

Partitioning should be revisited when the model, network, battery, regulations or operating environment changes.

3. Models for Constrained Hardware

A model deployed on an embedded device must satisfy several constraints simultaneously:

• flash or non-volatile storage for program code and weights;
• RAM for activations, buffers, stack and operating-system functions;
• supported numerical formats and operators;
• maximum inference time;
• energy per inference;
• acceptable accuracy under real sensor conditions.

Parameter count alone does not determine feasibility. Runtime memory may be dominated by intermediate activations, and an unsupported operator can prevent deployment even when the model is small.

Model Architecture Selection

Compact convolutional networks, depthwise-separable convolutions, temporal convolutional networks, small recurrent networks and efficient transformer variants may be considered according to the task. For time-series sensing, a carefully designed feature-extraction pipeline followed by a small classifier may outperform an unnecessarily large deep network in energy efficiency.

Architecture search for the edge should include hardware constraints. A model with fewer mathematical operations is not always faster if its operations are poorly supported by the target processor. Benchmarking on the actual device is essential.

Quantization

Quantization represents weights, activations or both with fewer bits. In post-training quantization, a trained floating-point model is converted after training. In quantization-aware training, the training process simulates reduced-precision effects so that the model learns to tolerate them.

If a model has \(P\) parameters and each parameter uses \(b\) bits, the weight-storage requirement, ignoring metadata and alignment, is

\[

M_{weights}=\frac{Pb}{8}\text{ bytes}.

\]

For example, one million 32-bit weights require

\(1,000,000\times 32/8=4,000,000\) bytes, approximately 4 MB using decimal units. With 8-bit weights, the requirement is approximately 1 MB. Actual deployment memory can be greater because of scales, zero-points, tensor alignment and activations.

A common affine mapping from a real value \(x\) to an integer representation \(q\) is

\[

q=\operatorname{clamp}\left(\operatorname{round}\left(\frac{x}{s}\right)+z,q_{min},q_{max}\right),

\]

where \(s>0\) is the scale, \(z\) is the zero-point, and the clamp operation restricts the result to the representable integer range. Dequantization is approximately \(x=s(q-z)\). Symmetric quantization often uses a zero-point near zero; asymmetric quantization can represent ranges with unequal positive and negative limits more efficiently.

Quantization reduces memory traffic and may enable integer hardware acceleration. It can, however, reduce accuracy, especially when activation distributions contain outliers. Calibration data should reflect deployment conditions, including environmental noise and representative users or machines.

Pruning

Pruning removes parameters or connections judged to contribute little to the output. Unstructured pruning removes individual weights and may produce high sparsity, but it only improves speed when the hardware and software exploit irregular sparsity. Structured pruning removes channels, filters, neurons or blocks, producing a smaller dense model that is generally easier to accelerate.

Pruning can be performed iteratively: train a dense model, remove selected structures, fine-tune, validate, and repeat. Accuracy, latency and energy must be measured after compilation because nominal sparsity does not guarantee practical improvement.

Knowledge Distillation

In knowledge distillation, a compact student model learns from a larger teacher model. The teacher's probability distribution contains information about similarities among classes. A typical distillation objective combines the ordinary supervised loss with a teacher-matching loss:

\[

L=(1-\alpha)L_{hard}+\alpha L_{soft},

\]

where \(0\leq\alpha\leq1\), \(L_{hard}\) measures error against true labels, and \(L_{soft}\) measures disagreement with teacher outputs. Some formulations use a temperature parameter to soften probabilities. The exact loss must be selected consistently with the task and implementation. Distillation is not guaranteed to preserve minority-class or rare-event performance, so evaluation must include those cases.

Optimized Inference

Deployment often involves converting a model to a runtime such as TensorFlow Lite for Microcontrollers, ONNX Runtime, TVM-based systems or a vendor-specific SDK. Compilation may fuse operators, tile memory accesses, use SIMD instructions or map kernels to an NPU. Unsupported operators may cause fallback to a slower CPU path. A deployment report should record model version, numerical format, operator set, compiler, firmware, hardware and benchmark conditions.

4. Hardware and Accelerators

Microcontrollers

Microcontrollers integrate a processor, memory and peripherals in a low-power package. They are appropriate for always-on sensing, control and low-bandwidth inference. Their constraints make static memory planning, fixed-point arithmetic and careful buffer reuse important.

Gateways and Embedded Computers

Gateways provide more memory and computational capacity and can aggregate many devices. They can host containerized services, local databases, video analytics and multiple models. Their energy consumption and cost are higher than those of a microcontroller, but they offer easier software updates and richer observability.

CPUs, GPUs, DSPs and NPUs

CPUs are flexible and widely supported. GPUs provide parallel throughput, particularly for vision, but may have higher power demand. DSPs are efficient for signal processing and repetitive numerical operations. Neural processing units and other AI accelerators can deliver high performance per watt for supported operators. Selection should consider not only peak operations per second but also memory bandwidth, supported precision, thermal behavior, software tools and lifecycle availability.

5. Evaluating On-Device Inference

Accuracy must be evaluated on data collected from the actual deployment context. Laboratory accuracy can conceal failures caused by sensor placement, temperature, vibration, lighting, microphone variation, class imbalance and concept drift.

Important metrics include:

• task metrics such as accuracy, precision, recall, F1 score, mean absolute error or intersection-over-union;
• false-alarm and missed-detection rates for safety-related events;
• mean, percentile and worst-case latency;
• energy per inference and average power;
• memory footprint and flash usage;
• throughput and number of supported devices per gateway;
• availability during network or cloud outages;
• model-update success rate and rollback time.

For binary classification, precision is the fraction of predicted positives that are correct, while recall is the fraction of actual positives detected. These metrics should not be replaced by accuracy when classes are highly imbalanced.

A practical test matrix should include normal, boundary, noisy, adversarial and failure conditions. Measurements should be repeated and reported with the operating frequency, supply voltage, ambient temperature, compiler settings and input rate.

6. Federated and Distributed Learning

Training can also be distributed. In federated learning, devices train locally on private data and send model updates rather than raw records to an aggregator. A basic synchronous procedure is:

1. The server sends a global model to selected clients.

2. Each client trains for a specified number of local steps or epochs.

3. Clients return updates and summary information.

4. The server aggregates the updates and distributes a new global model.

A common weighted aggregation is

\[

w_{t+1}=\sum_{k=1}^{K}\frac{n_k}{\sum_{j=1}^{K}n_j}w_{t+1}^{(k)},

\]

where \(w_{t+1}^{(k)}\) is client \(k\)'s locally updated parameter vector and \(n_k

the number of training examples used by that client. This weighted average is associated with the basic FedAvg approach under assumptions that data and optimization are sufficiently well behaved. It is not a universal solution for non-identically distributed data, intermittent clients or malicious updates.

Federated learning improves data locality but does not automatically guarantee privacy. Model updates may leak information, and malicious clients may poison training. Secure aggregation can prevent the server from viewing individual updates, while differential privacy adds controlled noise to limit information leakage. Both approaches can reduce accuracy or increase communication and computation. Device authentication, update signing, rate limits, anomaly detection and robust aggregation are also relevant.

Federated learning is especially useful when data cannot be centralized because of privacy, ownership, bandwidth or regulatory restrictions. It is less attractive when devices have very limited energy, data are highly nonrepresentative, or a reliable central training pipeline is already available.

7. Security, Privacy and Governance

An edge device is physically accessible in many deployments. Attackers may extract firmware, alter model files, inject sensor signals or observe inference outputs. Essential controls include secure boot, hardware-backed key storage, signed firmware and model updates, encrypted communication, least-privilege services, debug-port protection and rollback mechanisms.

Privacy protection begins with data minimization. A system should collect and retain only what is necessary. Local feature extraction, deletion of raw data after processing, access controls and auditable retention policies reduce exposure. However, derived features and model outputs can still reveal sensitive information.

AI governance requires clear accountability for model behavior. Designers should document training data provenance, intended use, known limitations, thresholds, update procedures and human override mechanisms. High-impact applications may require risk assessment, explainability appropriate to the audience, records of significant changes and compliance with applicable data-protection, cybersecurity, product-safety and sector-specific requirements. Edge deployment does not remove the responsibility of the system owner.

8. Detailed Illustrative Case: Predictive Maintenance in a Pumping Station

Background

Consider a municipal pumping station containing electric motors, pumps and vibration sensors. The existing system uploads continuous vibration streams to a cloud platform. Engineers receive an alert when a cloud model detects bearing degradation.

Problem

The station has intermittent connectivity and a cellular data budget. A cloud round trip sometimes exceeds the five-second operational target. Continuous transmission also increases energy use and exposes detailed information about equipment operation. The system must detect abnormal vibration early while continuing to protect equipment during network outages.

Analysis

The engineers examine a representative data set containing normal operation, imbalance, cavitation and bearing-fault events. They discover that faults have different signatures at different motor speeds. A model trained only on laboratory data produces false alarms in the field because of mounting differences and temperature variation.

The required functions are divided as follows:

• the sensor node samples vibration and computes a short-time spectral representation;
• a microcontroller runs a compact anomaly classifier;
• the gateway combines vibration, temperature and motor-current features and runs a larger model;
• the cloud stores summaries, supports fleet-level analysis and trains periodic model updates.

Raw vibration is retained locally for a short diagnostic window and is uploaded only when an event is detected or an engineer requests it.

Approach and Solution

The team first establishes a floating-point reference model. It then trains a smaller student model using supervised labels and teacher outputs. Structured pruning removes low-value channels, and integer quantization is introduced using calibration data from multiple stations. The team compares three deployment candidates: microcontroller-only inference, gateway inference and hierarchical inference.

The selected design uses a two-stage detector. The microcontroller performs a low-cost screening operation. Ordinary windows are discarded after a compact feature summary is created. Suspect windows are sent to the gateway, where a richer model estimates the fault category and confidence. If confidence is low, the system records the event for later review rather than automatically shutting down the pump.

Before deployment, the engineers measure latency at the highest sampling rate, energy during normal and alarm operation, RAM during peak activation, and behavior during gateway and network failure. Model updates are signed and can be rolled back. The system dashboard reports model version, sensor health, event rate and confidence distribution.

Outcome

The architecture reduces routine communication and enables immediate local alerts. The cloud remains valuable for fleet-wide comparison and retraining, but it is no longer part of the critical protection loop. Field testing reveals that one sensor mounting configuration creates a distribution shift; retraining with representative data reduces false alarms. The final operational decision uses both model confidence and engineering rules, illustrating that edge AI should support—not obscure—domain expertise.

Learning Points

1. Partitioning should follow safety and latency requirements, not available cloud functionality alone.

2. Compression must be evaluated on real hardware and field data.

3. A hierarchical design can reserve expensive computation for uncertain cases.

4. Failure handling, model rollback and sensor-health monitoring are part of AI deployment.

5. Human and engineering controls remain necessary in safety-relevant applications.

9. Best Practices and Contemporary Developments

A robust edge-AI project should establish a measurable baseline before optimization. The team should profile memory, latency and energy, identify the true bottleneck, apply one optimization at a time, and revalidate task performance after each change. Representative calibration and test data are essential. Reproducible builds, model cards, device inventories and continuous monitoring support maintainability.

Additional best practices include:

• design for graceful degradation when connectivity or accelerators fail;
• separate safety-critical control logic from probabilistic AI where appropriate;
• use confidence thresholds validated for the cost of false positives and false negatives;
• monitor data drift, sensor drift and performance drift;
• keep a signed, tested rollback model;
• minimize retained personal and industrial data;
• benchmark the complete application rather than isolated kernels;
• document energy measurements and thermal conditions.

Contemporary development is moving toward specialized low-power NPUs, event-driven and neuromorphic computing, sparse and mixed-precision models, on-device continual learning, split learning, privacy-preserving analytics and automated hardware-aware neural architecture search. These developments are promising but introduce new concerns, including difficult programming models, nonstandard toolchains, update safety and limited evidence under long-term field conditions.

Challenges and Limitations

Edge AI does not eliminate the fundamental difficulties of machine learning. Small models may have reduced accuracy, poor calibration or weak performance on rare conditions. Non-identically distributed device data complicate federated training. Quantization can damage sensitivity to small signals. Pruning may provide no speedup on hardware without sparse-kernel support. Energy estimates can be misleading if radio startup and idle costs are omitted.

Other limitations include limited explainability, hardware obsolescence, supply-chain risk, physical tampering, costly field maintenance and difficulty reproducing bugs across heterogeneous devices. Edge systems also create a tension between local autonomy and centralized governance: local decisions improve resilience, while central management supports consistency and accountability. Sound engineering makes this trade-off explicit rather than assuming that either cloud or edge is always superior.

Chapter Summary

Edge AI places inference and sometimes learning near IoT data sources, reducing latency, communication and dependence on continuous connectivity. TinyML specializes in deploying useful models on highly constrained microcontrollers, while distributed intelligence coordinates devices, gateways and cloud services.

Cloud–edge partitioning should be based on deadlines, privacy, reliability, computation, energy and communication requirements. Latency and energy can be estimated using explicit component models, but final decisions require measurements on real hardware. Quantization reduces numerical precision and storage, pruning removes parameters or structures, and knowledge distillation transfers behavior from a large teacher to a small student. None guarantees practical improvement without deployment benchmarking.

Microcontrollers, gateways, CPUs, GPUs, DSPs and NPUs offer different trade-offs in flexibility, performance, power and software support. Evaluation must include task quality, worst-case latency, memory, energy, availability and robustness to field conditions. Federated learning keeps training data local but requires safeguards against update leakage, poisoning and nonrepresentative data.

Secure boot, signed updates, privacy-by-design, model documentation, monitoring and rollback are essential parts of professional deployment. The pumping-station case illustrates a hierarchical design in which local screening protects latency and availability while gateways and cloud systems provide richer analysis and fleet learning.

Key Terms

Edge AI: Artificial-intelligence processing performed near the source of data.

TinyML: Machine learning deployed on highly resource-constrained embedded devices.

Distributed intelligence: Coordinated intelligence shared across devices, gateways and cloud systems.

Gateway: An intermediate computing and networking node connecting edge devices to larger platforms.

Cloud–edge partitioning: Allocation of sensing, inference, storage and learning tasks across system layers.

Quantization: Representation of numerical values with reduced precision.

Scale: A factor used to map an integer representation to a real-valued quantity.

Zero-point: Integer offset used in an affine quantization mapping.

Pruning: Removal of model parameters or structures considered unnecessary.

Structured pruning: Removal of complete channels, filters, neurons or blocks.

Knowledge distillation: Training a compact student model using information from a larger teacher model.

Activation: Intermediate output produced by a neural-network layer.

Accelerator: Specialized hardware designed to execute computational workloads efficiently.

Inference: Use of a trained model to produce predictions.

Federated learning: Collaborative model training in which data remain on participating clients.

Secure aggregation: Protocol that hides individual client updates from an aggregator.

Differential privacy: A privacy framework that limits the influence of any one record on an output.

Concept drift: Change over time in the relationship between inputs and target outcomes.

Worst-case latency: The maximum or conservatively bounded execution time under specified conditions.

Model rollback: Replacement of a deployed model with a previously validated version.

Review Questions

Short Answer Questions

1. Distinguish edge AI from TinyML.

2. Why can local inference improve IoT privacy and availability?

3. What is the purpose of quantization-aware training?

4. State one limitation of unstructured pruning.

5. Why does federated learning not automatically guarantee privacy?

Long Answer Questions

1. Explain the major factors involved in deciding whether inference should run on a device, gateway or cloud.

2. Compare quantization, pruning and knowledge distillation as model-compression methods.

3. Discuss the roles of microcontrollers, gateways and AI accelerators in an IoT architecture.

4. Explain how latency, communication energy and reliability should be evaluated in a cloud–edge system.

5. Describe the security and governance controls required for a fleet of edge-AI devices.

Analytical / Application Questions

1. A sensor has a 1 MB model containing 1,000,000 parameters stored with 8-bit weights. Estimate the weight storage if the weights are changed to 32-bit floating point, ignoring metadata. What other memory should be measured before deployment?

2. Design a partitioned architecture for a wearable fall-detection system. Justify where sensing, inference, storage, alerts and retraining should occur using latency, privacy and energy criteria.

3. An industrial classifier has excellent laboratory accuracy but frequent field false alarms. Propose an evaluation and remediation plan involving data collection, calibration, model compression checks, drift monitoring and human oversight.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes TinyML from general edge AI?

A. TinyML requires a cloud connection for every prediction.

B. TinyML targets highly resource-constrained embedded devices.

C. TinyML is limited to image-classification applications.

D. TinyML always uses floating-point arithmetic.

Correct Answer: B. TinyML targets highly resource-constrained embedded devices.

Question 2

In the latency decomposition, which component is most likely eliminated by fully local inference?

A. Sensing time

B. Local preprocessing time

C. Network upload and download time

D. Postprocessing time

Correct Answer: C. Network upload and download time

Question 3

Ignoring metadata, how much storage is required for 1,000,000 parameters represented with 8-bit weights?

A. 125,000 bytes

B. 1,000,000 bytes

C. 4,000,000 bytes

D. 8,000,000 bytes

Correct Answer: B. 1,000,000 bytes

Question 4

What is a principal advantage of structured pruning?

A. It guarantees no loss in accuracy.

B. It removes complete structures that ordinary dense hardware can more easily exploit.

C. It increases the number of model parameters.

D. It requires no retraining or validation.

Correct Answer: B. It removes complete structures that ordinary dense hardware can more easily exploit.

Question 5

In affine quantization, what does the scale represent?

A. The number of training epochs

B. The mapping factor between integer and real-valued quantities

C. The number of classes in the model

D. The network transmission rate

Correct Answer: B. The mapping factor between integer and real-valued quantities

Question 6

Which statement about federated learning is correct?

A. Raw training data must always be sent to the server.

B. It eliminates the possibility of malicious model updates.

C. Clients can train locally and send model updates for aggregation.

D. It can only be used when all clients have identical data.

Correct Answer: C. Clients can train locally and send model updates for aggregation.

Question 7

Why can a model with fewer mathematical operations still be slower on an edge device?

A. Operations are irrelevant to runtime.

B. The model may use operators poorly supported by the target hardware.

C. Smaller models always require more network bandwidth.

D. Quantization prevents all acceleration.

Correct Answer: B. The model may use operators poorly supported by the target hardware.

Question 8

Which metric is especially important when missed detections have serious consequences?

A. Recall

B. Flash color

C. Number of model layers alone

D. File-name length

Correct Answer: A. Recall

Question 9

What is a key purpose of secure boot in an edge-AI device?

A. To increase training-data diversity

B. To ensure that only authorized software is executed during startup

C. To convert floating-point weights to integers

D. To remove the need for model evaluation

Correct Answer: B. To ensure that only authorized software is executed during startup

Question 10

In the illustrative pumping-station case, why was hierarchical inference selected?

A. It sends all raw data continuously to the cloud.

B. It applies a low-cost screen first and reserves richer analysis for suspect cases.

C. It prevents any model updates.

D. It requires every sensor to use a GPU.

Correct Answer: B. It applies a low-cost screen first and reserves richer analysis for suspect cases.