10.5 IoT DC3 in Industrial Practice: Case Studies
10.5.1 The IoT DC3 Platform Architecture and Its Industrial Fit
When an industrial IoT (IIoT) platform is deployed on the ground, most teams get stuck on the very two embarrassments raised in Section 10.1.1: data cannot get out, so AI cannot use it; and AI can only watch, not act. Traditional IoT platforms tend to solve only one of the two: strong at device connectivity, or strong at data analysis — few close the "collect — normalize — analyze — execute — feed back" chain into a loop. IoT DC3's design goal is precisely to fill these two gaps.
IoT DC3's architectural skeleton
IoT DC3 adopts a microservice architecture, split into several independent services along four main lines: connection, storage, rules, and intelligence. What deserves elaborating here is not its module list but the general design judgments behind it — judgments that transfer to any industrial platform:
First, closing the loop is where the platform's value lies. If the two gaps above are not filled, however complete the connectivity and however deep the analysis, they remain two capabilities fighting separate battles. The platform's value lies precisely in closing "collect — normalize — analyze — execute — feed back" into a loop — the industrial landing of the data loop discussed in Chapter 2.
Second, independent scaling. Device access scale, data write volume, and rule-triggering complexity are rarely of the same order of magnitude; deploying them separately is what allows each to scale independently. When a factory grows from 1,000 PLCs to 5,000, for example, only the driver instances need to scale horizontally — the rule engine stays untouched.
Third, a two-stage decision pattern: "fast judgment + deep analysis." Deterministic, latency-sensitive judgments (temperature above threshold for a sustained period, sudden pressure drop, loss of device heartbeat) go to the rule engine, with a designed response target at the millisecond level; complex semantic understanding and reasoning (natural-language queries, cross-device correlation analysis) go to the Agentic Center, at seconds to minutes. Each does its own job — models do not replace rules, nor the other way around.
Fourth, a unified data model. Raw values collected by drivers are wrapped into structured objects (carrying device ID, point ID, timestamp, value, and quality status), written into time-series storage for historical analysis, and at the same time pushed onto a message queue for rules and AI to consume in real time — the upper layers face only a stable data model and message contract (the trade-off between time-series write and query bandwidth was covered in detail in Chapter 5).
Fifth, a pluggable agent-orchestration layer. The Agentic Center does not process streaming point values directly; it steps in only when complex semantics are required — parsing an operator's natural-language query, invoking time-series queries, aggregating and analyzing to produce an answer, and, when necessary, issuing parameter-adjustment commands through tool calling.
In DC3 these five judgments land respectively in the Manager Center, the data center, the rule engine, and the Agentic Center (Figure 10-11), but they are design principles shared by any industrial platform — understanding the judgments themselves has more transfer value than memorizing any module name.
Table 10-5 lists each core module's responsibility boundary and typical industrial deployment scenarios, to help you confirm, during architecture design, "which module should own a given task." This mapping proves very useful in real projects — we have seen teams force device write-back control logic into the rule engine until rule complexity spun out of control, and we have seen time-series downsampling pushed off to AI models, producing astronomical inference bills.
Table 10-5: Responsibility boundaries of the IoT DC3 core modules
| Module | Core responsibilities | Suited scenarios | Unsuitable scenarios |
|---|---|---|---|
| Manager Center | Device registration, thing-model management, driver binding, state tracking | Device online/offline management, point configuration changes, driver hot-loading | Real-time data computation, model inference, complex event-sequence processing |
| Data center | Time-series data ingestion, metadata management, historical queries, message routing | Point-value storage, historical trend analysis, data export, real-time data distribution | Condition evaluation, rule orchestration, session management |
| Rule engine | ECA condition evaluation, alarm actions, command dispatch, work-order triggering | Threshold alarms, periodic checks, heartbeat loss, device linkage | Complex model inference, unstructured understanding, long-period trend analysis |
| Agentic Center | Agent orchestration, LLM reasoning, natural-language queries, multi-step decisions | Natural-language operations, cross-device anomaly analysis, repair advice, parameter-tuning advice | Millisecond-level response judgments, fixed-logic execution, pure data replay |
Key designs for the industrial fit
Driver extensibility is a make-or-break concern for industrial deployment. No factory enjoys the quiet luxury of "one protocol only" — a single production line may simultaneously hold legacy sensors on Modbus RTU, new PLCs exposing OPC UA, and special-purpose machines wrapped in proprietary protocols. IoT DC3 decouples the driver implementation through the fine-grained interfaces of its Driver SDK: each driver is an independent, executable Spring Boot module that implements connection-lifecycle, read/write, health-check, and other capability interfaces as needed, rather than inheriting one unified base class; at startup, the driver registers its metadata with the Manager over gRPC (the business registration of DriverRegisterService, not a registration with any service-registry center). This lets a team support, at the same time, official drivers for complete protocols and private drivers that "read the registers and assemble the data themselves." The design thinking behind the driver architecture against the broader background of protocol fragmentation was unfolded in the "unified access layer" section of Chapter 4.
At the persistence layer, IoT DC3 uses PostgreSQL by default (with the TimescaleDB time-series extension), using its automatic partitioning (hypertable) and continuous aggregation (continuous aggregate) to relieve write bottlenecks. In industrial scenarios, write bandwidth is usually far higher than query bandwidth — a point we expanded in detail in Chapter 5.
Where to draw the boundary between the rule engine and AI is a question asked again and again in practice. The rule engine handles deterministic logic of the "if A and B, then do C" kind, responding in milliseconds; the Agentic Center handles reasoning that must understand "why is this abnormal" and "what happens next," responding in seconds to minutes. The two work in concert: once the rule engine captures a definite anomaly signal, it can trigger an immediate alarm, and it can also package the context and send it to the Agentic Center to request deep analysis and a recommended decision. This preserves the speed of emergency response while leaving room for reasoning in complex scenarios. This two-stage "fast judgment + deep analysis" pattern is also a continuation of the architectural-layering principle we stressed when discussing the data loop in Chapter 2.
On the northbound integration side, IoT DC3 opens device management, data query, rule configuration, and command dispatch through standard REST APIs, supporting integration with existing MES (Manufacturing Execution System), ERP (Enterprise Resource Planning), and work-order systems. The APIs are designed as JSON over HTTPS, so industrial IT teams can call them directly, with no need to develop a dedicated protocol-adaptation layer. In most factory deployments this lets IoT DC3 play the role of a "data middle platform" — it does not replace the fieldbus; instead, after normalizing all device data, it gives upper-layer applications a clean semantic interface.
10.5.2 A Production-Line Data Acquisition and Monitoring Case on IoT DC3
The previous section described IoT DC3's module division and message routing; here we come down to one concrete production line. We use a hypothetical SMT (Surface Mount Technology) electronic-assembly line to walk through the full flow — device registration, driver binding, data acquisition, and a Grafana monitoring dashboard. All device parameters, line layout, IP addresses, and protocol configurations are by design and do not map to any deployed project.
Scenario setup
The SMT line in our example has four core pieces of equipment: a reflow oven, a pick-and-place machine, a solder-paste printer, and a linking conveyor. Each device exposes Modbus TCP holding registers through its PLC, providing process points such as temperature, pressure, and rotational speed. The goal is to connect these devices to IoT DC3, store the point data in the time-series database, and then build a real-time monitoring dashboard with Grafana.
Device registration and driver binding
The first step of device access is creating a device record in IoT DC3's Manager Center. Each device receives a globally unique device number and is bound to the corresponding Modbus TCP driver. Below is a hypothetical API call that registers a reflow oven, binds the Modbus TCP driver, and at the same time defines thing models for three points (the data is illustrative and points to no specific device model).
POST /api/v1/device/save
{
"deviceCode": "SMT-REFLOW-001",
"deviceName": "Reflow Oven-1",
"tenantId": "demo-tenant",
"productId": "reflow-oven-v1",
"driverCode": "ModbusTcpDriver",
"driverConfig": {
"host": "<plc-ip>",
"port": 502,
"slaveId": 1,
"timeout": 3000,
"retryCount": 3
},
"pointModels": [
{
"pointId": "PM_TEMP_TOP",
"pointName": "Top Zone Temperature",
"unit": "℃",
"registerType": "HOLDING_REGISTER",
"registerAddress": 0,
"dataType": "FLOAT",
"multiplicand": 0.1,
"precision": 1,
"readWrite": "R"
},
{
"pointId": "PM_TEMP_BOTTOM",
"pointName": "Bottom Zone Temperature",
"unit": "℃",
"registerType": "HOLDING_REGISTER",
"registerAddress": 2,
"dataType": "FLOAT",
"multiplicand": 0.1,
"precision": 1,
"readWrite": "R"
},
{
"pointId": "PM_CONVEYOR_SPEED",
"pointName": "Conveyor Speed",
"unit": "cm/min",
"registerType": "HOLDING_REGISTER",
"registerAddress": 4,
"dataType": "INT16",
"multiplicand": 1.0,
"precision": 0,
"readWrite": "R"
}
]
}The response returns the device ID and activation status. Once the driver service receives the device binding information, it automatically opens a Modbus TCP connection to {host, port, slaveId} and reads all holding registers on the configured polling cycle (2 seconds, for example). The driver maintains a mapping table from points to register addresses, so one poll can batch-read a contiguous address block (such as 0–5), reducing network round trips. When the data reaches the data center, it is written into TimescaleDB. The data flow of this process is shown in the figure below.
Building the Grafana monitoring dashboard
Once the time-series data is written, Grafana connects to TimescaleDB through a PostgreSQL data source. The following is a panel query that filters the last hour of temperature data by device number and point:
SELECT
event_time,
value
FROM point_value
WHERE
device_id = 'SMT-REFLOW-001'
AND point_id = 'PM_TEMP_TOP'
AND event_time >= NOW() - INTERVAL '1 hour'
ORDER BY event_time ASC;The panel shows several curves: top-zone temperature and bottom-zone temperature; conveyor speed can use a bar chart or a line chart; plus a gauge for the average over the last few minutes. Panels are grouped by device, with the refresh interval set to a configurable value (5 seconds in the example). The configuration is reusable — when a new device is added, only device_id and point_id need to change; the panel layout and query logic stay the same.
Engineering checklist
After device access is complete, verify the following key points:
- Mapping between device number and driver configuration: the deviceId returned by registration must match the deviceCode in the driver configuration; otherwise the driver cannot find the corresponding driver configuration in the Manager Center, and the data will never be reported.
- Modbus register addresses and data types: these must align strictly with the actual PLC's holding-register map. An address off by one byte reads wrong values; the byte order of floating-point values (big-endian/little-endian) must match the PLC vendor (most Siemens and Mitsubishi PLCs use big-endian).
- Polling frequency and thread-pool capacity: the polling cycle should not be too short (below 1 second, for example, most slaves on an RS-485 link fail to respond in time). Keep the thread-pool size proportional to the number of devices, so that one high-latency device does not block the polling of the others.
- Grafana query performance: once TimescaleDB holds data on the order of tens of millions of points, index the timestamp column (event_time) and keep query windows within 2 hours. For 24-hour queries, use downsampling aggregate functions (avg, max) instead of raw point queries.
- De-duplication: by default, the IoT DC3 driver de-duplicates points whose values are unchanged across two consecutive polls and does not report them again, reducing storage overhead. To keep the raw trace of every cycle, turn off the de-duplication switch in the driver configuration.
Although this flow is based on an SMT line, the steps — device registration, driver binding, point configuration, and dashboard creation — apply equally to other Modbus TCP devices. The core is thing-model design — mapping register addresses, data types, scaling factors, and units into clear semantic labels, on which all downstream analysis tools (rule engines, AI models, reports) depend, rather than on raw register numbers.
10.5.3 A Case Integrating Rule-Engine Alarms with Predictive Maintenance
The previous section's monitoring dashboard solved "seeing"; this section solves "acting" — automatically invoking AI inference, generating work orders, and notifying operations when an anomaly occurs. Continuing the hypothetical SMT line scenario, we layer a rule engine on top of the reflow-oven motor-temperature data stream to demonstrate the complete chain from condition evaluation to work-order closure. All device parameters, API addresses, and thresholds are by design.
Rule configuration: sustained over-limit detection
On site, the motor's normal temperature is 60–75 °C. The alarm threshold is set to 80 °C, and it must persist for more than 10 seconds. A momentary violation may be a glitch; only a sustained violation indicates a real anomaly. The IoT DC3 rule engine supports sliding-window conditions: the window length and aggregation function are configured directly in the rule, with no need to bring in a separate stream-processing framework. The rule configuration (in JSON; all fields are illustrative examples and point to no real system or project).
{
"name": "Motor temperature over-limit sustained 10 seconds: alarm and prediction",
"enabled": true,
"note": "Source: example scenario from this book; threshold and duration only illustrate the rule structure.",
"description": "When the reflow-oven motor temperature average stays above 80°C for 10 seconds, trigger an alarm and run the follow-up actions.",
"conditions": [
{
"pointId": "smt-reflow-oven.motor1.temperature",
"operator": "GREATER_THAN",
"value": 80,
"windowSeconds": 10,
"aggregation": "AVG"
}
],
"actions": [
{
"type": "HTTP",
"url": "http://ai-inference-service:8080/predict/rul",
"method": "POST",
"headers": { "Content-Type": "application/json" },
"body": {
"deviceId": "${device.id}",
"temperature": "${point.value}",
"timestamp": "${point.timestamp}"
},
"timeoutMs": 5000
},
{
"type": "WORK_ORDER",
"priority": "HIGH",
"assignee": "maintenance-team",
"title": "Reflow-oven motor temperature anomaly alarm",
"description": "Motor temperature sustained above 80°C; AI inference request triggered."
},
{
"type": "NOTIFICATION",
"channel": "DINGTALK",
"target": "maintenance-group"
}
]
}On a fixed cycle, the rule engine computes the average point value inside the window and compares it with the threshold. Once the condition is met, it executes three actions in sequence: calling the AI inference service API to obtain a remaining-useful-life prediction, creating a high-priority maintenance work order, and sending an alarm notification to the DingTalk group. Action types can plug into different work-order systems or notification channels through extension adapters.
The key design point: the rule engine does not wait for the AI result before creating the work order. The three actions can execute concurrently, and a failure on any one path does not affect the others. Even if the AI inference service times out or returns an error, the work order and the notification still go out — avoiding the loss of the entire alarm because of a fragile AI downlink.
Practical boundaries and a checklist
Dividing decision rights between rules and models: threshold judgments belong to the rule engine — low latency, high explainability; complex pattern recognition is left to AI models. Do not try to emulate a model with rules, and do not make models handle pure on/off judgments. A rule's output can serve as a model input feature (such as frequency count or window average), but feature extraction should not be the rule engine's job.
The resource cost of sliding windows: every rule maintains a sliding window in platform memory. When a line reaches thousands of points, push the window computation for high-frequency points down to the edge gateway, and keep platform-layer rules to cross-device or global logic only. Make the window length a system-configurable parameter rather than hard-coding it, so field personnel can adjust thresholds without restarting rules.
Work-order de-duplication: when the same device triggers the same rule several times within a short period, set a cooldown interval. For example, within 10 minutes, do not create a new work order for the same device under the same rule; instead, append the new events to the timeline of the existing work order. Otherwise the operations group will receive floods of duplicate alarms within minutes, and fatigue will teach the operators to ignore them.
Work-order lifecycle and closed-loop verification: once a rule-created work order enters the pending state, its closure should be tracked. The rule engine can subscribe to work-order state-change events: if a work order stays open for a long time while the same device keeps exceeding the limit, the alarm level should be escalated or a higher-level administrator notified. This state feedback loop turns rules from one-shot event triggers into a cyclic control loop.
Without the rule engine, "acting" would degenerate into purely manual alarm viewing. This case shows the automated decision path from data to work order. For a recap of the engineering-practice points, see the methodology checklist in Chapter 14.