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 converts the state judgments produced by understanding into executable action sequences. A traditional rule engine handles simple propositions like "IF attribute value > threshold THEN trigger action," which suits operating conditions with clear thresholds and fixed scenarios. But in a complex system of coupled variables, a single threshold is far from enough — energy-efficiency control of an air-conditioning system must weigh outdoor temperature, indoor occupancy, electricity-price periods, and start-stop energy costs at the same time; it is a multi-objective optimization problem. The decide stage's task is to find, within the parameter space, an action sequence that satisfies the constraints: inside deterministic boundaries, chained rule engines handle known scenarios; in non-deterministic situations, an AI model (such as the large language model (LLM) integrated in IoT DC3's Agentic Center) infers the next step from its understanding of the state. The output of the decision is a structured command set containing device identifiers, operating parameters, priority, and expiry time.
The execute stage is the critical step that carries commands back into the physical world, covering the full chain of command decomposition, queue scheduling, protocol-driver adaptation, and receipt confirmation. After the decision component issues a command, the scheduler locates the target device's protocol driver, translates an abstract command 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; once executed, the device writes back a point value and the loop closes. This is the stage where things most often go wrong — network latency, protocol mismatches, offline devices, conflicting commands — so the execution layer needs retry mechanisms, idempotency guarantees, and conflict detection. IoT DC3's Manager Center takes on the role of command scheduling and receipt verification, guaranteeing reliable downlink delivery through a unified command queue. In the traditional model, the execution step depends on manual human operation; in the closed-loop model, execution is programmatic, millisecond-level, coordinated operation across multiple devices.
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 — the planning component generates two structured commands under the building's energy-management policy: (1) turn on the southeast conference room's air conditioning, setpoint 24 °C, medium fan speed; (2) raise the northwest office area's air-conditioning setpoint by 2 °C. It appends an evaluation cycle — re-trigger the loop in 30 minutes.
The execute stage — the command scheduler locates the protocol drivers for the corresponding air-conditioning units, translates the operations into Modbus register-write commands, and routes them through the gateway to the field devices. The two units execute and return confirmation codes.
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 outputs an action sequence: (1) pause that AGV's task; (2) reassign its task to another AGV with sufficient charge; (3) issue the return-to-charging-station command; (4) update both AGVs' routes to avoid the congested zone. The execution module delivers the sequence's four actions through the platform layer's downlink channel to the corresponding driver services. After several rounds of iteration, the reasoning module pulls the point values again and confirms that the low-battery AGV has started moving toward the charging station and that the reassigned task has been taken over and is running on its planned route.
Throughout this flow, no human intervened. Through the iterating cycle of understanding — planning — execution — understanding again, the intelligence layer completed the full closed loop from data input to physical action write-back. The key to this cycle's efficiency lies not in optimizing any single stage to its extreme, but in the frequency and stability of closed-loop iteration among the three — together they determine the system's overall latency from detecting a problem to responding physically.
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.