In mass concrete construction, temperature control success is 70% pouring and 30% curing. Traditional curing relies on manual inspections and experience-based judgment — "check the thermometer, feel the surface, throw on an extra blanket if it seems hot." This approach suffers from data lag (often missing the optimal intervention window) and subjective decision-making with no traceable curing records. Our intelligent curing solution, built on the TG Cloud Mode wireless temperature monitoring system, integrates real-time monitoring, multi-tier alarms, and curing decisions — upgrading concrete curing from "experience-driven" to "data-driven."
1. Three Pain Points of Traditional Curing
| Pain Point | Traditional Approach | Consequence |
|---|---|---|
| Data Lag | Manual hourly readings; night monitoring often skipped; peaks missed | Missed peak windows; violations discovered too late |
| Decision Lag | Data → Excel → meeting → crew instruction, 1–3 day cycle | Decisions arrive after temperature curve has already turned |
| Missing Records | Curing actions communicated verbally, no systematic logging | No complete curing traceability for acceptance inspection |
2. Intelligent Curing System Architecture
Our intelligent curing system uses the TG Cloud Mode wireless temperature network as its data foundation and the online temperature monitoring software platform as its decision hub, forming a complete "sensing → analysis → alarm → response → recording" closed loop.
2.1 Five-Layer Architecture
| Layer | Name | Function | Implementation |
|---|---|---|---|
| L1 | Sensing | Multi-point real-time temperature acquisition | Embedded temperature sensors + TG wireless loggers + ambient sensors |
| L2 | Transmission | Wireless data backhaul to cloud | 4G (customizable: WIFI/RJ45/LoRa/RS485/CAN), with power-loss resume and offline catch-up |
| L3 | Platform | Data storage, computation, visualization | Cloud: 3D thermal field / history curves / real-time reports / formula engine / section cloud maps |
| L4 | Alerting | Multi-tier threshold triggers + multi-channel push | 6 preset alarm rules + custom formulas + Email/MQTT/SMS/WeChat push |
| L5 | Response | Curing action execution & logging | Manual intervention: insulation / cooling water / steam adjustment, with platform logging |
2.2 Four Key Indicators for Curing Decisions
The system automatically computes these indicators from real-time data to inform curing decisions:
| Indicator | Computation | Curing Decision Trigger |
|---|---|---|
| Max Internal Temp | max(all internal sensor current values) | ≥ 70°C → activate cooling pipes or adjust mix |
| Core-Surface Differential | abs(max(internal) - surface temp) | ≥ 25°C → enhance surface insulation |
| Surface-Ambient Differential | surface temp - ambient air temp | ≥ 20°C → add insulating blankets or tarps |
| Cooling Rate (24h) | avg(24h-ago internal) - avg(current internal) | ≥ 2°C/day → reduce cooling flow / increase insulation |
3. Multi-Tier Smart Alarms — The Trigger Mechanism for Curing Intervention
Alarms are the core triggering mechanism for intelligent curing. The system supports 6 preset alarm rules with customizable thresholds and push channels.
3.1 Six Preset Alarm Types
| Alarm Type | Condition | Default | State | Curing Recommendation |
|---|---|---|---|---|
| Internal High Temp | max(internal) ≥ {val} | 75°C | On | Activate cooling pipes, adjust mix |
| Core-Surface Differential | abs(max(internal) - surface) ≥ {val} | 25°C | On | Enhance surface insulation cover |
| Surface-Ambient Differential | abs(surface - ambient) ≥ {val} | 20°C | On | Add insulating blankets or tarps |
| Inlet-Outlet Water Temp Diff | abs(inlet - outlet) ≥ {val} | 10°C | Off | Inspect cooling system, prevent localized overcooling |
| Cooling-Water vs Internal Diff | abs(internal - cooling water) ≥ {val} | 20°C | Off | Raise cooling water temp to avoid thermal shock cracking |
| Cooling Rate Exceeded | avgB - avgNow ≥ {val} | 2°C/day | Off | Reduce cooling flow, increase insulation |
💡 Alarm Design Philosophy
The first 3 alarms (internal high temp / core-surface diff / surface-ambient diff) are mandatory GB 50496 control indicators, enabled by default. The last 3 (inlet-outlet water diff / cooling water diff / cooling rate) require cooling pipes and are disabled by default — users enable as needed.
3.2 Custom Alarms + Multi-Channel Push
Beyond the 6 presets, the system supports fully custom alarm formulas. Users can combine sensor IDs (e.g., TG01_04), 24h-before values (e.g., TG01B04), and max() / avg() / abs() functions into any condition expression.
Alarm push channels:
- Platform Popup: instant display on the real-time overview page
- Email: configurable recipient list
- MQTT: integration with third-party SCADA or central control systems
- SMS: urgent alerts pushed directly to site managers
⚠️ Alarm Testing Feature
The system includes a built-in "alarm rule testing" function that fetches real-time sensor values and evaluates alarm formulas to verify triggering. During debugging, test with email first, then enable SMS after verification.
4. Intelligent Curing Strategy Recommendations
4.1 Insulation Curing (Most Common)
- Trigger: surface-ambient differential ≥ 20°C, or cooling rate ≥ 2°C/day
- Action: Cover surface with plastic film + straw mats / quilts / insulating blankets
- Technical note: material overlap ≥ 100mm; double coverage at corners and edges
4.2 Cooling Pipe Curing
- Trigger: internal max temp ≥ 70°C, or heating rate ≥ 5°C/h
- Action: Staged water flow — warm water (25-30°C) during heating phase, ambient water at peak, gradually reduce during cooling
- Technical note: inlet water vs internal concrete differential ≤ 25°C; flow change ≤ 20% per hour
4.3 Steam Curing
- Trigger: winter construction, ambient ≤ 5°C, or precast element accelerated hardening
- Action: Four stages — standing → heating → constant temp → cooling, heating rate ≤ 15°C/h, constant ≤ 60°C, cooling ≤ 10°C/h
5. Real-World Curing Scenarios
Case 1: Summer Raft Foundation Crack Prevention
- Commercial complex raft 45m × 35m × 3.0m, summer pour (ambient 32°C)
- 48h post-pour: center 72°C, surface 45°C, differential 27°C (exceeded 25°C threshold)
- Alarm triggered automatically via email + platform popup
- Action: 2 layers insulating quilt + 1 layer plastic film on surface
- 3h after intervention: differential dropped to 21°C; 72h peak 74°C (within 75°C limit)
Case 2: Winter Pier Shaft Steam Curing
- High-speed rail pier 6m × 3m × 12m, winter (ambient -5°C)
- Post-pour: ambient persistent -5°C, concrete surface 2°C (below 5°C freeze protection)
- Extended alarm rule: surface ≤ 5°C, dual-channel push (email + SMS)
- Action: insulated enclosure + steam curing, heating rate strictly ≤ 15°C/h
- Result: internal stabilized at 55°C during constant-temp phase, strength compliant at 72h
6. Outlook: From Smart Alarms to Smart Closed-Loop
The current system achieves a semi-closed loop of "monitoring → alarm → manual response." The next evolution is fully automated closed-loop control:
| Control Target | Actuator | Control Logic | Status |
|---|---|---|---|
| Cooling Water Flow | Electric control valve (4-20mA / Modbus RTU) | Internal temp PID: fast rise → high flow; post-peak → taper off | Via DG System |
| Steam Valve | Solenoid valve + temp controller | Staged steam adjustment per curing schedule | Via DG System |
| Insulation Cover | — | Manual application/removal (can't be automated) | Manual Only |
The hardware foundation for closed-loop control already exists — our DG-series 4G DTU has Modbus RTU interface capability, directly connectable to solenoid valves, control valves, and pumps. With existing real-time temperature data and alarm rule engine, full automatic temperature control closed-loop only requires adding a PID controller and valve mapping logic in the software layer.
7. DG System: AI-Driven Automatic Temperature Control
In real-world deployments, the DG-series 4G DTU is far more than a "communication gateway" — it serves as an edge computing node that combines data acquisition with intelligent control. Working in tandem with TG temperature monitoring sub-devices over a wireless mesh network, the DG system establishes a complete "Sense → Fuse → Decide → Act" automatic temperature control pipeline.
7.1 The Dual Role of the DG System
| Role | Function | Targets |
|---|---|---|
| Data Acquisition | Aggregates TG sub-device data + reads DG-attached sensors and instruments | Temperature (TG channels), cooling water flow (flow meter), digital switch states (pump on/off), VFD current frequency |
| Control Execution | Receives control commands from cloud platform, writes to actuators via Modbus RTU | VFD frequency setpoint, electric ball valve opening (0–100%), solenoid valve on/off |
7.2 Multi-Source Data Fusion: The AI Decision Input Layer
The DG system uploads a complete data snapshot to the cloud platform every 2 minutes. The AI decision engine aggregates the following dimensions to build a complete thermodynamic profile of the concrete:
| Data Dimension | Source | Typical Value | AI Decision Use |
|---|---|---|---|
| Internal Temp Field | TG sub-device (32 channels) | Core 72.3°C / Top surface 48.1°C / Bottom 52.6°C | Determine thermal phase (heating / peak / cooling) |
| Cooling Water Flow | DG-attached flow meter (pulse / 4-20mA) | Current 2.5 m³/h | Assess whether cooling intensity is sufficient |
| VFD Frequency | DG reads VFD via Modbus RTU | Current 35 Hz | Baseline for computing adjustment direction & magnitude |
| Ball Valve Opening | DG reads valve positioner via Modbus RTU | Current 60% | Cross-validate with flow data, confirm actuator state |
| Digital Switch States | DG digital input (DI) channels | Pump running = 1 / stopped = 0 | Verify actual actuator state, detect command failures |
| Ambient Weather | TG external ambient sensor / weather API | Air 32°C / Wind 3 m/s | Auxiliary input for surface heat dissipation rate |
7.3 AI-Assisted Decision Engine
Upon receiving a complete DG data snapshot, the cloud platform's AI decision engine executes a five-step pipeline:
AI Decision Pipeline (executes every 2 minutes)
Data Preprocessing
Clean outliers (sensor disconnects, spikes), interpolate missing points, align all dimensions to a unified timestamp
State Identification
Based on thermal field gradients and historical trends, auto-classify concrete into: Heating (dT/dt > 0 sustained for >30 min), Peak Plateau (|dT/dt| ≤ 0.5°C/h), Cooling (dT/dt < 0 sustained for >30 min)
Multi-Indicator Assessment
Simultaneously compute 5 indicators — max internal temp, core-surface differential, surface-ambient differential, cooling rate (24h), inlet-outlet water temp differential — and compare each against GB 50496 thresholds
Control Strategy Generation
Based on current phase + indicator deviation, AI generates specific control commands: target VFD frequency, target ball valve opening, pump on/off
Safety Gate Check
Validate control commands against safety boundaries: cooling water vs internal differential ≤ 25°C, flow change ≤ 20%/h, VFD frequency range 10–50 Hz. Any violation triggers downgrade to conservative strategy with manual confirmation push.
💡 Core AI Decision Logic
Unlike simple "threshold → action" mapping, the DG system's AI engine uses a multi-variable coordinated control strategy. For example: when internal temperature rises, the AI does not simply "go to maximum flow." Instead, it considers the current VFD frequency, valve opening, and cooling water temperature differential constraints to compute a gradual target value curve, ensuring smooth regulation without overshoot or secondary thermal hazards. After each adjustment, the AI evaluates the effect over 2 reporting cycles (4 minutes); if the trend persists, it initiates the next round of fine-tuning.
7.4 Command Delivery: Cloud-to-Edge Closed-Loop Execution
AI-generated control commands are dispatched from the cloud platform to the on-site DG device, which writes them to actuators over the Modbus RTU bus:
| Control Target | DG Output Method | Example Command | Granularity | Status |
|---|---|---|---|---|
| VFD Frequency | Modbus RTU Write Holding Register (FC 06) | Addr 40001 ← 35.0 Hz | 0.1 Hz | Deployed |
| Ball Valve Opening | Modbus RTU Write Holding Register / 4-20mA analog output | Addr 40002 ← 65 (65%) | 1% | Deployed |
| Solenoid Valve | DG digital output (DO) channel | DO1 ← ON | Binary | Deployed |
7.5 Complete Automatic Temperature Control Closed Loop
Connecting all the links above, the DG-system-driven automatic temperature control forms a complete closed loop:
TG Sensors
Temp Data
DG Aggregation
Multi-Dim Snapshot
Cloud Platform
AI Decision Engine
DG Execution
Modbus Commands
Actuators
VFD / Valve / Pump
🎯 DG Automatic Temperature Control — Key Capabilities
- Multi-Dimensional Sensing: Simultaneously collects temperature, flow, frequency, valve opening, and switch states — 5 dimensions, far beyond traditional temperature-only approaches
- AI Decision Making: Multi-variable coordinated control rather than simple threshold triggers — smooth strategy, no overshoot, no secondary hazards
- Closed-Loop Execution: DG writes directly to VFDs and electric ball valves via Modbus RTU — 2-minute full cycle, zero manual intervention
- Safety Failsafe: Every command passes a safety boundary check before delivery; violations trigger automatic downgrade with manual confirmation push
- Effect Tracking: Post-command effect evaluated within 4 minutes; automatic fine-tuning if target not met
📋 Conclusion
The core of intelligent curing is not "automation replacing people," but giving human decisions a data foundation. The current TG Cloud Mode already delivers 24/7 continuous monitoring, second-level alarm push, and complete curing traceability, dramatically improving the timeliness and credibility of curing decisions. As closed-loop control hardware gets integrated, curing will move into true "unattended" operation — but curing strategy design, alarm threshold calibration, and anomaly judgment will always require the professional experience of engineers.