2.1 From the Classic Four Layers to a New Architecture for the AI Era
Before diving into the architecture, a note on the engineering reference used throughout this book. Our running example is IoT DC3 (github.com/pnoker/iot-dc3, AGPL-3.0) — an open-source, cloud-native industrial IoT platform with multi-protocol access that is evolving toward AI-agent capabilities, and a real project the author has maintained for years. It is not chosen because it is perfect, but because every layer can be taken apart: how protocols are normalized, how services are split, how data flows, and how intelligence stays bounded. Section 2.3 dissects its microservice architecture; Chapters 10 and 14 return to it from an industrial-adaptation and an end-to-end practice perspective. Whenever the chapters ask how something lands in a real system, DC3 usually has an answer.
2.1.1 The Position and Limits of the Classic Four-Layer Architecture
A typical IoT project opens like this: the team puts real effort into sensor selection, gateway deployment, and getting the network to run — and then stalls at application development. Device data streams up without pause, but the temperature field is named temp, the vibration sensor vib_value, and the current I_A — raw fields from different vendors with no unified semantics. An operator hand-configures a rule, "raise an alarm when the motor temperature exceeds 75 °C," and when workshop temperatures climb in summer, the alarms ring non-stop. Asked for the production line's overall efficiency over the past week, the data turns out to be scattered across device logs, the time-series database, and the MES — one cross-system trend query takes half a day. (This is an illustrative scenario, not a real project case.)
These difficulties are not lapses in project management; their roots lie at the architecture level. Does the architecture of the Internet of Things (IoT) actually cover the complete chain from data acquisition to decision execution? The structural weaknesses that the classic four-layer architecture exposes under this question are precisely the underlying force driving its continued evolution.
2.1.1.1 From Three Layers to Four: A Middle Layer That Had to Be Added
The IoT architecture was not born with four layers. Early projects borrowed IT layering thinking and mostly applied a three-layer model — the sensing layer, the network layer, and the application layer. This directly inherited the layering logic of the internet and the telecom network: acquisition (at the edge), transmission (through the pipe), processing (in the cloud). The three-layer model holds up for small-scale prototype validation and a few hundred nodes, but the moment a project enters production, problems surface: who manages device registration? Where do massive volumes of time-series data get stored? How are tenants isolated? These common capabilities had no fixed home, so every application project built its own "foundation" — the result was repeated wheel-reinvention and maintenance costs spiraling out of control.
Many teams realized that the common capabilities had to be abstracted out. Leaf through the several widely accepted reference architectures, domestic and international, and you find that every party, independently, added a platform support layer between the transmission layer and the application layer — responsible for foundational capabilities such as device management, data storage, and message routing. The two terminology systems ended up at the same place by different roads: between "transmission" and "application" there must be a bridging infrastructure layer.
That is the origin of the classic four-layer reference architecture: the sensing layer, the network layer, the platform layer, and the application layer, with security capabilities running through all of them. It became the foundational framework cited by many IoT product documents and technical specifications.
2.1.1.2 Each Layer Does Its Own Job
The sensing layer is the IoT's "nerve endings" — temperature sensors, RFID tag readers, GPS modules, cameras, and the field gateways that aggregate their signals. Its mission is reliable acquisition. What gets acquired differs enormously from one scenario to the next — in a factory, the current value in a PLC register (a point value); in a building, serial-port data from temperature and humidity sensors; in a city, traffic density from roadside radar — but at the architecture level, what never changes is "converting the physical state of the analog world into a digital signal with a timestamp."
The network layer is the "highway" of data transmission. It spans short-range wireless technologies such as ZigBee and Wi-Fi, low-power wide-area (LPWAN) technologies such as LoRaWAN and NB-IoT, and long-distance wired and cellular technologies such as 4G/5G and fiber Ethernet. The network layer does not care about data content; it only guarantees that packets travel from point A to point B, and that commands travel from point B back down to point A.
The platform layer is the new layer with no counterpart in the three-layer model. Device registration and management, time-series data storage and query, message routing and distribution, rule engines and event processing, multi-tenant isolation, and role-based access control (RBAC) — once standards organizations pushed the platform layer out as an independent layer, application developers no longer had to care about infrastructure questions such as "where is data stored" and "how do devices register," and could concentrate on writing business logic. This was the key step that moved the whole architecture from "usable" to "good to use."
The application layer is the user-facing interface, deeply bound to its industry. It may be the manufacturing execution system (MES) of a production line, the energy-management backend of a building, or the traffic-dispatch big screen of a city. Every industry has its own business processes, interface styles, and certification norms, but the platform layer screens all these differences out, so the application layer can care only about "what to do," not "how to connect."
2.1.1.3 Three Cracks: Pressing from "Usable" to "Good to Use"
The classic four-layer architecture has supported countless IoT projects, from smart meters to connected-vehicle dispatch. But its design philosophy is "data flows up, commands flow down" — in essence a sense → transmit → store → display linear pipeline, not an understand → decide → execute closed loop. Faced with complex IoT scenarios, this design exposes three structural cracks.
The first crack: data processing lags. Data sets out from the sensing layer, crosses the network layer to the platform layer, and only after being stored can the application layer consume it. Take a cold-chain monitoring scenario: a freezer-cabinet temperature sensor reports every 30 seconds, the reading travels through a Wi-Fi gateway into the cloud platform's storage, and the application layer polls for it — between the temperature crossing its limit and an operator seeing the alarm sit multiple rounds of transmission, queuing, and query latency. For scenarios that demand a fast response (motor overload protection, cold-storage temperature excursions), the platform layer does no real-time inference, and the application layer is too far from the data. The architecture reserved no place for "judging near the source," and a device may enter an irreversible, dangerous state before its decision window opens.
The second crack: weak intelligent decision-making. The application layer can hold rules, but the rules are defined by hand and cannot cover a complex, dynamic environment. Correlations between device states, trend prediction, automatic discovery of abnormal patterns — none of these capabilities has a fixed home in the four-layer architecture. On a packaging line, a motor's vibration rises, its current fluctuates, and air pressure drops — each of the three parameters sits inside its normal threshold when viewed alone, but together they mean the bearing is about to fail. The rule engine in the classic architecture can only handle "single variable over threshold" judgments and cannot integrate multimodal joint inference at the architecture level. Project teams either build their own machine-learning pipeline and bolt it on beside the platform layer, or rely on human-watched dashboards and manual decisions.
The third crack: the missing closed loop. The default interaction mode of the classic architecture is "human reads data → human judges → human operates the device." Even where automation rules were introduced, they are logic people wrote and froze in advance — not a system that perceives changes in its environment and re-plans its actions on its own. Data flows from the sensing layer to the application layer and stops; there is no path back — between sensing and acting, a continuous adaptive loop is missing. Real industrial control loops need fast decisions; an IoT system without closed-loop support can only produce after-the-fact analysis reports and cannot intervene in the physical world in real time.
Table 2-1 Boundary-check checklist for the classic four-layer architecture
| Check item | Typical problem | Architectural root |
|---|---|---|
| Sensing layer | Data formats inconsistent, field names without semantics | The architecture enforces no thing-model abstraction, so each vendor goes its own way |
| Network layer | Protocol fragmentation, bloated gateway stacks | The network layer ignores application semantics; there is no unified access abstraction |
| Platform layer | Rule engines support only single-variable thresholds | The architecture leaves no module slot for multi-source joint decision-making |
| Application layer | Business logic coupled with data governance | The platform layer is not abstract enough, forcing the application layer to handle low-level details |
| Security layer | Authorization policies scattered across layers, auditing difficult | "Security throughout" is a principle; in practice there is no unified policy point |
The classic four-layer architecture solved the problem of bringing the IoT from nothing into existence. But as AI begins to permeate every line of code, can the IoT be upgraded from "collect → display" to "understand → act"? The answer depends on opening up new territory between the platform layer and the application layer — the intelligence layer.
2.1.2 New Architectural Requirements in the AI Era: The Intelligence Layer
The classic four-layer architecture usually leaves business judgment to the application layer, but does not prescribe how semantic governance, model operation, tool authorization, and execution audit should divide responsibilities. As systems scale, teams often encounter data without unified semantics, rules that false-alarm as operating conditions change, and trend analysis without enough context. Large language models (LLMs) and edge intelligence provide new means of interaction and analysis, but model "understanding" and "planning" are probabilistic outputs, while execution must remain constrained by deterministic policies, permissions, and safety boundaries. The intelligence layer is added here to make those responsibilities explicit, not to claim that machines can execute unconditionally on their own.
2.1.2.1 Two Driving Forces: One from the Cloud, One from the Edge
This closed loop must exist, because it has to withstand technical pressure from two directions at once.
The first direction comes from the cloud: the practical maturity of large language models. A point-value table records "37.5 °C," but a model trained on technical documentation and operations logs can understand which device this value belongs to, which production line it sits on, the historical failure rate of similar devices at this value, and that "≥38 °C" in the maintenance manual means the load must be reduced. It translates raw data into actionable intelligence — but only if the architecture provides a mechanism that connects the LLM's reasoning results to actual device control commands. If the application layer must hand-assemble the context before every LLM call and hand-write hundreds of lines of code to issue commands after getting a result, then "intelligence" degenerates into duplicated labor repeated in every application project, and the architecture's generality is sharply discounted.
The second direction comes from the edge: the practical maturity of edge intelligence. Many industrial scenarios impose millisecond- or sub-second-level latency requirements — if a high-speed stamping press fails to recognize a vibration anomaly within the next stroke cycle, the consequence may be a damaged die. Compared with a cloud round trip plus inference processing, edge inference, though it has its own cost, at least avoids the latency uncertainty of the wide-area network. This demands a place in the architecture that can run lightweight models or rule engines near the devices and influence device behavior directly or nearby. The industry's common division of labor is the three-tier collaboration of "train in the cloud, infer at the edge, respond on the device": the cloud trains models on the full historical data and pushes them down to edge nodes for low-latency inference, while the device side delivers only the final, split-second response.
Viewed separately, one force raises the ceiling of "understanding" while the other compresses the time window of "execution." Together they point to one conclusion: a dedicated functional layer must be carved out inside the application layer, pulling the logic of "understand the data → make the decision → drive execution" out of scattered code and completing it in one place.
2.1.2.2 The Three Core Responsibilities of the Intelligence Layer
In this book's reference architecture, the intelligence layer is drawn as a fifth logical layer between the platform and application layers to make the responsibility boundaries of AI reasoning, task orchestration, and controlled execution explicit. It need not map to a fixed process in deployment: a small system may implement it as a module inside an application, while a large system may separate it into an independent Agent Runtime. Every later reference to "five layers" means logical layering by responsibility; it does not mistake deployment topology for an architectural definition. Its core responsibilities break into three parts: Understand → Planning → Execution.
Understand: drawing on the structured point-value streams aggregated at the platform layer, together with device metadata, historical patterns, and domain knowledge, form an explainable description of the current state. This may cover threshold judgment, anomaly detection, trend extrapolation, and ranking candidate root causes; correlation or temporal order alone does not prove causation, and a root-cause conclusion still requires validation by mechanism, experiment, or field evidence.
Planning: having understood the state, generate one or more executable action sequences. Planning must handle multi-objective conflicts — energy saving versus comfort, output versus equipment life, shedding load versus avoiding shutdown. The planning engine may be a set of mathematical models (linear programming, for example) or a step description generated by an LLM, depending on the scenario's complexity and explainability requirements.
Execution: convert the plan into device commands the platform layer understands, and deliver them to actuators over the existing command channel. Once execution completes, feedback must be collected — did the device respond to the command, and what is its new state after responding — to form closed-loop correction.
These three steps are not a one-shot, three-stage pipeline; they loop continuously: execution feeds back into understanding, understanding corrects the next plan, and planning generates new actions. The value of the intelligence layer lies not in how large a model it runs, but in converging this loop into a capability with explicit inputs, outputs, and governance boundaries, so business applications can focus on workflows. Model selection, tool calling, permissions, approval, and recovery are developed in Chapter 7; here the purpose is only to establish the responsibility model.
2.1.2.3 The Intelligence Layer in Interaction: AI-Augmenting the Four-Layer Architecture
With the intelligence layer added, the application layer's internal structure becomes "business-logic components + the intelligence layer." Data flow is no longer a one-way street pointing only upward. An "upstream acquisition flow" leads from the physical world to the digital side; a "downstream execution flow" carries reasoning results back to the physical world. A feedback flow then returns the new post-execution state to the reasoning module.
In architectural roles, the division of labor among the intelligence layer, the platform layer, and business applications is clear: the intelligence layer reads data and writes commands through the platform layer, and exposes to business applications both its reasoning results and decision entry points open to intervention. The platform layer need not understand "why this value is written"; the intelligence layer need not care how data is partitioned inside the database. Together they turn a long-standing gray zone of the architecture — the joining of decision and execution — into a standardized interface.
IoT DC3 uses its Agentic Center to demonstrate one implementation of this division of labor: it manages models and conversations and calls platform capabilities through controlled tools. With the August 2026 source snapshot 987c96d50 as the boundary, Agentic's internal Spring AI @Tool entry and the Gateway's external MCP Tool catalog are related but distinct. The latter derives candidate tools from the platform API/resource catalog and versioned OpenAPI snapshots and declares only the Tools capability. The project does not subscribe to real-time point-value streams or execute an automatic closed loop by default. Whether device queries or point writes are available, and what risk level they carry, depends on the actual catalog, authorization, policy, and platform APIs; these capabilities cannot be inferred as available out of the box from the reference architecture. Tool catalogs, task state, approval, and recovery are left to Chapter 7.
2.1.2.4 Does Every Project Need an Intelligence Layer Inside the Application Layer?
Putting the intelligence layer into the architecture diagram does not mean every IoT project needs a page that talks to an LLM. Its essence is to carve out a dedicated logical region inside the application layer, responsible for the "understand → decide → execute" loop. If that loop is currently completed entirely by hand — operators watching the big screen to spot problems, phoning the field to act — then the classic four-layer architecture is enough. But once a project's scale demands stitching context across systems, or the required response time is within seconds, the human loop becomes the bottleneck.
The intelligence layer can be implemented as a lightweight anomaly-analysis and decision service, or as an Agent Runtime connected to an LLM and supporting multi-turn tasks and multi-objective planning. Once its logical position is clear, the deployment form can be selected flexibly for the scenario. This is the basic line of architectural design: assign responsibilities first, then choose the implementation; do not treat a particular process or model as the architecture itself. Deterministic thresholds and safety interlocks still belong to rules, PLCs, or a safety instrumented system (SIS); introducing an intelligence layer does not move them into a probabilistic model.
Table 2-2 A decision checklist for introducing the intelligence layer
| Criterion | If it leans toward "yes" | Recommendation |
|---|---|---|
| Do single-point decisions depend on people switching across multiple systems to gather context? | A single decision requires viewing data from more than two systems | Introduce the intelligence layer |
| Are rules adjusted frequently with season, operating conditions, or load? | Adjusted more than once a month | Introduce the intelligence layer |
| Do execution actions need to complete within the same system? | Decision and execution are split across different systems | Introduce the intelligence layer |
| Do users need natural-language interaction to query device status? | Operators report that "checking one value takes seven or eight menu clicks" | Introduce the intelligence layer |
| Is the decision cycle longer than 5 seconds? | Manual inspection cycles are on the order of minutes or hours | The classic four layers suffice |
This checklist offers no absolute thresholds — latency tolerance differs enormously across industries — but it provides a structured thinking framework that helps teams ask the right questions at an architecture review.
The central question in deciding whether an IoT project needs this closed-loop mechanism is not "does it use AI?" but whether cross-system understanding, non-deterministic judgment, and governed execution form an independent responsibility. If the system has only fixed thresholds, hard-real-time interlocks, or low-frequency manual viewing, the classic four layers are enough. Only when multiple applications need to reuse context, tools, and approval policies is it worth governing the intelligence layer independently as a fifth logical layer. Chapter 7 gives the deeper implementation; this chapter only puts the concept in place.
2.1.3 The Five-Layer Architecture Model at a Glance: Sensing, Network, Platform, Intelligence, Application
The previous section analyzed the core contradiction of the classic four-layer architecture in the AI era: the data has arrived, but the execution of understanding and decision-making lacks a standard layer. Operating-condition adaptivity, cross-device coordination, prediction ahead of events, and proactive intervention on the industrial floor need an independent logical layer that can converge reasoning and action capabilities. The five-layer reference architecture proposed in this book is an engineering cross-section drawn precisely for this contradiction — it embeds an "intelligence layer" between the platform layer and the application layer, turning the architecture from a one-way data pipeline into a closed-loop decision system. The following breaks down each layer's responsibilities and boundaries from top to bottom.
The application layer is the interaction interface between the IoT and its human users. In the classic architecture, the application layer embeds modules such as rule engines, data-analysis pipelines, and ticketing systems, and data terminates the moment it arrives through the platform layer. Under the five-layer architecture, the application layer no longer needs to wrap complex inference logic itself; it directly calls the intelligence layer's reasoning results or execution states to drive business flows such as operations dashboards, work-order dispatch, and production reports. The development focus of the application layer shifts from "writing judgment logic" to "designing workflows in which humans and AI collaborate."
The intelligence layer is the model's core new layer, handling three things in one place: understanding — restoring point-value sequences to device states and scenario semantics; planning — outputting a set of action sequences from rules or models; execution — sending the actions out through the platform layer's command interface and taking the execution feedback back. Introducing the intelligence layer strips the decision burden that the application layer had to carry in the classic four layers out into a reusable decision hub decoupled from business scenarios. It does not prescribe the AI technology — it can be driven by a large language model, or by a traditional rule engine plus real-time analysis models; what matters is standardizing the interfaces between "reasoning" and "execution." IoT DC3's Agentic Center is this layer's concrete practice: it connects large language models through the Spring AI framework and ships built-in tools for device query, point read/write, and command execution.
The platform layer is positioned as the convergence point of the infrastructure. It is responsible for device registration and lifecycle management, point template maintenance, time-series data storage and query, message routing, command dispatch, tenant isolation, and similar tasks. The platform layer does not care what the data "means"; it cares only "where it came from, where it should be stored, and to whom it should be sent." It exposes data-query interfaces and command-dispatch interfaces upward — these two groups of interfaces are precisely the intelligence layer's entrance and exit. The platform layer's design directly determines the system's scalability and data consistency. IoT DC3's Data Center and Manager Center carry the platform layer's core responsibilities in the architecture.
The network layer moves data from the field up to the cloud. In an IoT deployment, this layer directly determines transmission latency, bandwidth consumption, and whether devices can interconnect with the platform layer securely. The network layer does not change data content; it only packets, routes, and delivers according to the agreed protocols. In IoT DC3's practice, "unified access" is a job shared by two kinds of gateway, and the wording must be kept straight: the device-side IoT gateway is deployed in the field, where it aggregates the heterogeneous connections of peripheral devices nearby into a unified data channel — its role is field access aggregation; the platform-side Gateway service is the API gateway of the microservice system, responsible only for entry-point duties such as route dispatch and token validation — the parsing of protocols such as MQTT, CoAP, and HTTP does not happen there; it is carried out by the corresponding device driver services (detailed in Section 2.3.2).
The sensing layer is the entrance of the physical world. Peripheral devices such as sensors, RFID tags, PLC registers, and cameras acquire the raw signals, and IoT gateways convert those signals into point values carrying semantic labels. This layer's core output is a structured data stream — data objects containing device identifiers, timestamps, ranges, and units. One way to read it: the physical world has been fitted with a digital sensing system, and the starting point of every upper-layer decision depends on this layer's data quality and completeness.
The most crucial change in the five-layer architecture is not one more layer, but one more data path — a horizontal closed loop. In the classic four layers, data climbs from the sensing layer to the application layer and terminates there; if the application layer wants to write a decision back to a device, it must cross the platform layer and the network layer on its own to return to the sensing layer, and such "backflow code" gets re-implemented, error-prone, in every project. In the five-layer architecture, the intelligence layer coordinates the backflow: data enters the platform layer from the sensing layer through the network layer; the platform layer hands the data up to the intelligence layer; the intelligence layer understands the data, generates decision commands, and forwards them back down through the platform layer to the sensing layer. At the same time, the intelligence layer can also submit its processing results up to the application layer, completing the data chain. This closed loop converges the logic within the same architectural layer, reducing the latency and inconsistency that cross-layer calls bring. Concentrating the decision loop in the intelligence layer also keeps the platform layer relatively stable, avoiding frequent adjustments driven by business-logic change.
The table below shows how the four-layer and five-layer architectures differ on key dimensions. The thresholds and performance comparisons in the table are reference values; actual numbers vary with project scale, technology choices, and deployment conditions.
Table 2-3 Capability comparison of the four-layer and five-layer architectures
| Dimension | Classic four-layer architecture | Five-layer architecture of the AI era |
|---|---|---|
| Number of layers | 4 (sensing, network, platform, application) | 5 (sensing, network, platform, intelligence, application) |
| Data processing model | One-way collect → store → display; the application layer carries all decision logic | Closed-loop collect → understand → decide → execute; the intelligence layer converges reasoning and action capabilities |
| Decision triggering | Rule engine or human operation; response speed constrained by rule presets and human intervention | Driven by model inference combined with rules; supports real-time automatic decision and execution, with a standardized write-back path |
| Cross-layer call complexity | The application layer must coordinate the downward write-back itself, involving repeated API calls to the platform and network layers | The intelligence layer completes the write-back by calling the platform layer through standardized interfaces; upper-layer applications need not know the execution path |
| Intelligence integration | Every application re-implements its own AI integration — duplicated labor | The intelligence layer provides reasoning and execution uniformly; multiple applications share one decision hub |
| Typical fit | Scheduled data reporting, fixed-threshold alarms, static dashboard display | Operating-condition adaptive regulation, cross-device coordination, prediction ahead of events and proactive intervention |
Not every IoT system needs to adopt the five-layer architecture in full. For scenarios with small data volumes, fixed business logic, and purely manual monitoring, the classic four-layer architecture is simplicity enough, and adding an intelligence layer would only introduce needless complexity and maintenance cost. But once a system faces pressure from rich data, variable operating conditions, and high response requirements — industrial devices regulating themselves, production lines coordinating in real time, safety early warning — the missing intelligence layer becomes the bottleneck. What the five-layer model offers is not a template to copy verbatim but an evolutionary path that can be introduced incrementally: keep the existing services in the platform layer, start one intelligence-layer module alongside them, and gradually peel decision logic out of the application layer. With this trade-off understood, the practice discussions of IoT DC3's "one gateway + four center services" architecture in the chapters that follow gain their real architectural context — not a pile of tools, but one concrete landing of the five-layer model on a microservice framework. The intelligence layer corresponds to the Agentic Center; the Data Center and Manager Center carry the platform layer's core responsibilities; the Gateway is the network layer's unified entrance; and the Auth Center runs through all layers, delivering unified security control.
Convergence of Agentic IoT and AIoT (outlook). A growing number of platforms treat models, tool calling, and governance as independent capabilities, but that does not mean the intelligence layer will become a default component of every project in a particular year. The value of the five-layer model is to draw a boundary around model operation, tool authorization, and audit when there is a genuine need for natural-language interaction, cross-source analysis, or controlled automation. When none of those needs exists, a four-layer architecture with deterministic rules remains valid. Any capability to "execute directly on devices" should begin as read-only and gain authority step by step through offline evaluation, shadow operation, human confirmation, and limited automation.