2.2 The Shift to the Data Loop
2.2.1 From "Collect → Store → Display" to "Collect → Understand → Decide → Execute"
In the traditional IoT architecture, the default end point of data is "being seen by people." Sensors report readings, the network layer packages and transports them, the platform layer handles their ingestion into the database, and the application layer assembles them into charts and alarm lists. The human's task is to string the information together, judge the device's state, and decide whether to act. In scenarios with few devices and modest response requirements, this model runs quite stably. But when the deployment grows to a dozen cabinets and thousands of points, with a dozen large screens flashing at once in the monitoring room and alarm lights stretching into a solid sheet, the on-duty staff cannot possibly respond item by item. Alarms pile up, acknowledgment falls behind, and then work-order approval and command dispatch take their turn — by the time a device goes from an actually occurring anomaly to final disposition, an hour or more has often passed.
The real value of data lies not in being seen, but in driving change in the physical world once it is understood. The fundamental reason the architecture is shifting from "one-way display" to an "understand — decide — execute" closed loop is not technology anxiety; it is that business demands on response speed have broken through the limits of human processing.
The new data path is split into four consecutive stages: collect → understand → decide → execute. The collect stage still handles data acquisition and normalization, while the understand, decide, and execute stages splice together an "active write-back" path that traditional architectures never had. The key difference between the two models: the traditional end point is "to be seen," while the closed loop's end point is "a physical state changed."
This loop is also where the four words on the cover land: collection carries the trustworthiness constraint of Sense, understanding and decision carry the probabilistic boundary of Reason, execution carries the deterministic requirement of Act; Evolve is not a fifth stage on the loop but the way the loop gains authority level by level over time (developed in Section 7.5 and Section 14.4).
The flowchart below compares the data paths of the two models.
The understand stage differs fundamentally from traditional store-plus-display. The conventional approach puts data into a database and waits — for a person to query it, or for a threshold rule to raise an alarm. The understand stage does two things: state perception and trend prediction. State perception uses statistical or machine-learning models to recognize patterns in the data — does the decay of a specific frequency component in a device's vibration spectrum hint at bearing wear? Has the combination of parameters across multiple devices drifted out of the normal operating envelope? Trend prediction infers the short-term future from history — at the current rate of temperature rise, how much longer can the cooling system hold? Only when raw numbers and timestamps are restored as structured point values with physical meaning (PointValue, carrying semantic tags, units, timestamps, and tenant context) can a model answer "what does this value mean, where is it happening, and is it a precursor of an anomaly."
The decide stage turns state judgments into candidate actions. A traditional rule engine handles propositions such as “IF attribute value > threshold THEN trigger action,” which suits operating conditions with explicit thresholds and fixed scenarios. In a complex system of coupled variables, however, one threshold is not enough: air-conditioning efficiency must weigh outdoor temperature, occupancy, electricity-price periods, and start-stop energy costs together. The decide stage proposes candidate sequences within those constraints. Rule engines handle known cases inside deterministic boundaries; in nondeterministic cases, an AI model, such as an LLM integrated through IoT DC3's Agentic Center, may generate the next-step proposal. The output should be a structured candidate Action containing the target device, parameters, evidence, risk class, priority, and expiry. It becomes an executable command only after authorization, policy, conflict, and required confirmation checks pass.
The execute stage is the critical step that carries approved commands back into the physical world, covering parameter validation, risk policy, queue delivery, protocol-driver adaptation, and receipt confirmation. Once a command is approved, the platform locates the protocol Driver for the target device, translates an abstract operation such as "set temperature to 25.5 °C" into a Modbus register write or a PLC message, and delivers it over the appropriate communication link. The device receipt and post-execution readback are then used to determine whether the loop actually closed. This is where network latency, protocol differences, offline devices, duplicate delivery, and conflicting commands surface, so execution needs retries, idempotency, timeouts, conflict detection, and human takeover. In the IoT DC3 code boundary used by this book, the Manager Center maintains business metadata such as devices and accepts Driver business registration; point commands enter through Data, travel to the Driver over RabbitMQ, and return receipts over the messaging path. End-to-end latency and reliability must be measured in the target deployment; neither "millisecond-level coordination" nor guaranteed delivery follows from the architecture diagram alone.
Example: Energy-Saving Control in a Smart Building (Case Study)
The air-conditioning system of an office building is connected to a platform with an understand — decide — execute closed loop. Under the traditional model it runs on a fixed schedule: on at 8:00, off at 18:00, setpoint 24 °C. Holiday overtime or ad-hoc events can only be handled by filing a work order for a separate adjustment, and the energy waste is severe.
The closed-loop scenario runs on entirely different logic.
The collect stage — temperature-humidity sensors on each floor, CO₂ sensors, people-counting cameras, and power-monitoring devices on the indoor air-conditioning units report data continuously. The gateway normalizes the heterogeneous data into a stream of PointValues with semantic tags and feeds it into the time-series database.
The understand stage — the intelligence layer reads recent data from each zone, combines it with the building's staff entry-exit records and outdoor temperature and solar-radiation data from a weather API, and calls a pre-trained energy-consumption model for analysis. The model outputs two state summaries: "CO₂ concentration in the southeast conference room is high, dense occupancy detected, air conditioning is off — recommend starting cooling"; "the northwest open office area is sparsely occupied, perceived temperature is already near the setpoint, continued cooling may oversupply — recommend raising the setpoint."
The decide stage — under the building's energy-management policy, the planning component generates two structured candidate Actions: (1) turn on the southeast conference room's air conditioning at 24 °C and medium fan speed; (2) raise the northwest office area's setpoint by 2 °C. Each candidate carries its evidence, applicable period, risk class, and a reevaluation condition 30 minutes later.
The execute stage — a policy service checks authorization, comfort bounds, equipment interlocks, and conflicts. Only after automatic approval or human confirmation according to risk does the command scheduler locate the relevant protocol drivers, translate the approved operations into Modbus register writes, and route them through the gateway. The platform combines response codes with setpoint readback to determine whether the two units actually executed.
Thirty minutes later, the system collects data again. In the northwest office area the compressor's start-stop frequency has dropped, and the building's instantaneous power shows a perceptible change. The decision component iterates the next round of actions from the new inputs.
In this scenario, the system automatically eliminated excess cooling during non-essential periods. The energy improvement over the full operating cycle depends on building parameters, occupancy density, and outdoor weather conditions; actual figures vary case by case. Within this flow, the human shifts from continuous operator to supervisor and policy maker, stepping in to adjust only at boundary conditions such as holiday changes or large events. Figure 2-5 shows these interactions as a sequence diagram.
The core of the closed-loop model is not replacing people with AI, but turning data from a static exhibit into a dynamic stream of decisions. Every point value has somewhere to go — upward, a model can read its meaning; downward, it can change a device's state. Once you understand this loop, you can look at any IoT platform's design — where the data pipeline breaks, at which layer intelligence intervenes, whether the downlink command path is clear — and quickly locate the system's true stage of evolution. The loop also lays down the judgment framework for the later chapters' discussion of the intelligence layer's design and the engineering practice of IoT DC3's "one gateway + four center services" architecture.
2.2.2 The Intelligence Layer's Role in the Loop: Understanding, Planning, and Execution
The "collect → understand → decide → execute" cycle establishes a new end point for data — no longer "to be seen," but "to be changed." But once the cycle lands on an architecture, a concrete entity must exist to carry the cognitive load between understanding and execution. That entity is the intelligence layer. It is no longer merely a functional module of the platform layer or a set of algorithm containers; it is a cognitive hub that carries three iterating stages: understanding, planning, and execution.
The three form a closed, recursive loop: understanding derives a semantic judgment of the current state; planning turns that judgment into a pending action sequence; execution converts the sequence into commands the platform layer understands and completes the loop confirmation; then understanding runs again to verify the effect.
Understanding: From Point Values to State Awareness
Understanding is where the intelligence layer starts to grasp the current state of the physical world. The point values reported by sensors — temperature 85.3 °C, pressure 0.63 MPa, vibration amplitude 12.5 mm/s — each carry semantic tags, units, timestamps, and device context. But a single number by itself does not constitute "understanding." What this stage must solve is aggregating these discrete time-series points into a meaningful state description, with a confidence level or risk grade.
A traditional rule engine can only do "above threshold, raise alarm" matching — in essence a linear conditional check, with no "understanding" involved. An inference engine instead combines trend detection, pattern matching, and contextual device relationships into a comprehensive judgment. Its output is not a boolean but a structured state assessment. The following is pseudocode:
# Core logic of the inference engine
class InferenceEngine:
def assess(self, device_id: str, point_id: str, model: StateModel) -> Assessment:
# 1. Fetch the current value and the history window (from the platform layer's Data Center)
current_value = data_center.get_latest_point(device_id, point_id)
history = data_center.get_time_series(device_id, point_id, window_minutes=10)
# 2. Load device thresholds and failure models
thresholds = manager_center.get_device_thresholds(device_id)
patterns = model.get_failure_patterns(device_id)
# 3. Trend judgment
trend_slope = linear_regression_trend(history)
if trend_slope > thresholds.trend_critical:
return Assessment(status="critical",
description=f"Temperature keeps rising, slope {trend_slope:.2f}/min, above the critical threshold",
severity=Severity.HIGH)
# 4. Pattern matching
for pattern in patterns:
if pattern.matches(history):
return Assessment(status="predictive",
description=f"Matched preset failure pattern: {pattern.name}",
severity=Severity.WARNING)
return Assessment(status="normal", severity=Severity.NONE)This code shows the interaction boundary between the understanding stage and the platform layer: data is accessed but not owned, and the threshold models come from the Manager Center. The understanding stage's responsibility focuses on "translating numbers into semantics" — not persistence or protocol conversion.
Planning: Generating Action Sequences Under Multiple Objectives
Understanding answers "what is happening now"; planning must answer "what to do next." The planning stage takes a structured state assessment as input and produces one or more action sequences — and these actions must carry a clear order of execution, dependency conditions, branch paths, and fallback plans.
In a traditional IoT system, "what to do next" is hard-coded as one-to-one rule mappings: temperature > 85 °C → start the cooling pump. Such mappings suffice for single devices in stable scenarios, but in multi-device, multi-objective settings they immediately show their defects: starting the cooling pump may raise overall power consumption, cutting power may disturb the production line's takt time, and the side effects of scheduling several devices at once — a queue at the charging station, for instance — cannot be covered by any single rule.
Planning in the intelligence layer introduces multi-objective solving. Take warehouse logistics robots as an example: multiple automated guided vehicles (AGVs) share the charging stations, the aisle entrances, and the charging-station resources. The point values each AGV uploads include battery level, current position, load status, and current speed. The reasoning module determines that one AGV's battery is in a "critical shortage" state. The planning module's output is not a single "return to the charging station" command but a set of action sequences: first, pause that AGV's current transport task; second, reassign the unfinished task to the nearest other AGV with sufficient charge; third, send the low-battery AGV a command to return to the charging station; fourth, replan the route of the AGV that took over the task to avoid the current aisle congestion. The following is an example output structure:
Planning input:
DeviceStateAssessment(agv_07, status="battery_critical", location="zone_N", load=1)
Planning output:
ActionSequence(
actions=[
Action(id="a1", type="pause_task", target="agv_07"),
Action(id="a2", type="reassign_task", from="agv_07", to="agv_12"),
Action(id="a3", type="command", target="agv_07", cmd="return_to_charger"),
Action(id="a4", type="reroute", target="agv_12", avoid_zone="zone_N"),
Action(id="a5", type="reassess", delay_seconds=30, target="agv_07")
],
fallback=[
Action(id="f1", type="alert", severity="escalation", handler="dispatcher")
]
)This action sequence is not a pre-defined template; the planning module assembles it in real time from the current point values, device availability, task-queue depth, and charging-station occupancy.
Execution: Command Write-Back and Loop Confirmation
The action sequences produced by planning must be accepted and verified by the physical world. The execution stage's task is to translate each step of the sequence from a logical description into a command format the platform layer can parse, send it along the data loop's downlink channel to the driver service of the corresponding device, and then wait for the execution receipt.
Execution is more than a single dispatch. Closed-loop design requires loop confirmation after every execution — did the command arrive? Did the device act? Did the target point value move into the expected range? On receiving the confirmation receipt, the execution module triggers the next round of reasoning, pulls the relevant point values again, and verifies the effect. If the reasoning result still falls short, the planning module produces a new action sequence and keeps iterating until the state recovers or human intervention is triggered.
The key constraint is: the intelligence layer only decides; it never touches communication. The execution module does not generate Modbus/OPC UA messages directly, nor does it maintain device connection pools. It sends commands in a standardized format to the platform layer's driver services, which perform the protocol conversion and message transmission. This separation of duties lets the intelligence layer's models be upgraded or even replaced independently, while one set of platform-layer infrastructure simultaneously serves low-latency rule-based engines and complex reasoning engines built on large language models.
Closed-Loop Iteration in Logistics-Robot Route Planning
Stringing the three stages into one complete cycle with an example: several AGVs are running in a warehouse. The intelligence layer runs reasoning at a fixed interval (5 seconds). One AGV reports a battery level of 15% and is located at the warehouse's north end, far from the charging stations. From battery level, position, load status, and aisle congestion, the reasoning module concludes: this AGV's battery is in a "critical shortage" state — at its current load and route, the remaining charge is not enough to finish the current transport task and return to a charging station.
The planning module first produces candidate actions: (1) pause that AGV's task; (2) reassign it to another AGV with sufficient charge; (3) return the low-battery AGV to a charging station; and (4) reroute both vehicles around the congested zone. Scheduling policy must check job priority, load state, right of way, obstacle avoidance, and safety zones. Only preapproved low-risk policy may proceed automatically; replanning outside those bounds requires human confirmation. The platform sends approved actions to the relevant driver services. After several iterations, the reasoning module reads point values and task receipts again to confirm that the first AGV is moving toward the charging station and the replacement has taken over on the planned route.
When the task class, action range, and safety constraints have all been approved in advance, this flow can run without step-by-step human confirmation inside those bounds; that is not unconditional AGV autonomy. The understand — plan — execute — understand loop closes through fresh evidence, policy validation, execution receipts, and state readback, not iteration frequency alone. Any boundary violation, conflict, missing receipt, or state mismatch must stop the automatic path and transfer control to a person.
Summary of Architectural Boundaries
The intelligence layer is not an everything layer. It does no protocol conversion, persists no data, and handles no user authorization. Its role is explicitly confined to the cognition-intensive stages: understanding data, generating plans, driving iteration. Mapped onto the platform layer, this division of labor means that at deployment the intelligence layer only needs to communicate with a few core centers of the platform layer (the Data Center and the Manager Center) and never has to reach device-level links directly. The vendor behind the inference engine can be switched independently, or two intelligence engines can even run at once within the same tenant space — one rule engine for sub-second fast response, one LLM engine for minute-scale complex judgment.
This layered set of responsibility boundaries also foreshadows the later chapters' discussion of multi-agent collaboration. When multiple intelligence engines must coordinate actions, share state, or compete for resources, designing orchestration protocols and conflict-resolution strategies will be the engineering challenge that must be faced head-on in moving from "a single intelligence layer" to "distributed cognition."
2.2.3 Typical Problems Before the Intelligence Layer: Latency, Fragmentation, and Static Rules
Section 2.1.1.3 already listed the classic four-layer architecture's three structural cracks; this section focuses on the one most easily underestimated: rule conflict. Latency is visible and tangible, and fragmentation reveals itself gradually as the device fleet grows — but rule conflict shows no symptoms at all in normal times. Each rule checks out on its own; only when two rules fire at the same moment does the on-duty operator discover that the architecture offers no place to arbitrate between them. The soil in which rule conflict grows is static rules: thresholds and trigger conditions hard-coded at deployment cannot sense dynamic factors such as weather, occupancy density, or electricity-price periods; once operating conditions drift, rules that never seemed related collide.
A classic scene from a smart-lighting system illustrates this. The system has two rules: "if the light is dim, turn on the lights" and "while the projector is running, keep the lights off." When someone enters the room while the projector is running, both rules fire at once — rule A wants the lights on, rule B wants them off. A traditional condition-matching engine can only mechanically execute the last-matched rule or cut through by priority. It does not weigh the context — "a presentation is in progress and the person is sitting still" — to conclude "the lights should stay off."
It is the most easily underestimated for another reason too: the trouble surfaces on the troubleshooting side. The log usually records only the two rules executing one after the other, each one "executed correctly per its configuration," while the root cause points at the architecture — the classic four layers never reserved a module slot for "arbitration between rules."
This is where the intelligence layer's planning capability comes into play: rather than matching a single rule, it weighs multiple contextual states — time, occupancy, illumination, device status — to output a multi-objective action sequence that can adjust dynamically to feedback. The rule is no longer linear "if this then that" logic, but a multi-condition judgment generated by the reasoning engine in semantic space.
The Architectural Decision to Introduce the Intelligence Layer
Returning to the three cracks in Section 2.1.1.3, their common feature is: no layer of the architecture can carry both "understanding context" and "generating action sequences." The platform layer manages devices and data, and the application layer carries business logic, but "understanding" is scattered across every corner of the application code and still depends, in essence, on people translating sensor numbers. The intelligence layer pulls "understanding" and "deciding" out of fixed application code into a dedicated architectural layer that can be deployed flexibly at the edge, the gateway, or the cloud — accessing underlying data interfaces through tool calling, achieving cross-device general reasoning through semantic models, and handling dynamic context through a planning engine that blends rules with AI models.
Whether to introduce an intelligence layer depends on how strongly a project demands real-time response, device diversity, and dynamic decision-making. If the need is only to upload temperature data to the cloud for display, the intelligence layer is over-engineering. If there are motor-protection, conflict-resolution, or multi-device coordinated-control scenarios, introducing the intelligence layer directly determines whether the closed loop can exist at all.
Table 2-4 Decision capability before and after introducing the intelligence layer
| Problem dimension | Before the intelligence layer | After the intelligence layer |
|---|---|---|
| Decision latency | Data and commands must round-trip through the cloud; the loop is long, and response is measured in seconds | Reasoning can sink to the edge; the loop shortens, and response drops markedly |
| Rule maintenance | Rules are coded separately per device; maintenance rises sharply as device variety grows | Reasoning logic is reused via semantic tags; rules are maintained per semantic type rather than per device model |
| Context fit | Rule thresholds are fixed and blind to dynamic context; no comprehensive judgment on conflicts | Rule engine + AI model reason together, supporting dynamic thresholds and multi-objective planning, adjustable at runtime |
The cost of introducing an intelligence layer must also be assessed clearly: system complexity increases, model outputs are non-deterministic, and data quality, semantic labeling, evaluation, and governance all face higher requirements. A team should first quantify the losses caused by the problems described in Section 2.1.1.3, then use a small-scale experiment to compare the benefit of the intelligence layer with its error cost and long-term operational burden; without measurement, the return on investment cannot be assumed to be higher.