Concrete Temperature Monitoring
Data Analysis & Report Generation

Mass concrete temperature monitoring generates tens of thousands of data points daily. Extracting key insights and producing supervisor-approved standard reports from this data deluge is the core pain point for every monitoring engineer. We've built a complete data analysis system on the TG Cloud Mode platform: from real-time dashboards to historical curve tracing, from a custom formula engine to C5-9 standard reports, from ECharts visualization to one-click XLS export. This article unpacks each tool's capabilities and design rationale.

1. Data Analysis System Overview

The TG Cloud platform's data analysis system is organized into four layers:

2. Real-Time Dashboard — Global Situation at a Glance

The Dashboard is the most frequently accessed page. It provides a one-screen overview of core statistics:

3. History Curve Analysis — The Power Tool for Trend Discovery

3.1 Single-Device History Curves

Each TG device's data is stored in a PostgreSQL database (partitioned by device SN). The system provides paginated query APIs and dedicated curve pages:

• Data Query API: GET /api/data/history/{dtype}/{sn}, supports pagination (50/page, max 500) and date range filtering
• Curve Page: /data/chart/{dtype}/{sn}, full 32-channel time-series display
• Data Integrity: power-loss resume + offline catch-up ensures gapless curves

3.2 Multi-Group History Curves (ECharts Rendering)

The custom data module's history chart feature supports grouped rendering of multiple comparison curves:

• Group Management: logically group sensors (e.g., "Base Slab Group / Pile Cap Group / Pier Group")
• Time Aggregation: raw / hourly average / daily average — three modes for different analysis granularity
• Visual Interaction: ECharts time-series with zoom, drag, tooltip, legend filtering, save-as-image, print
• Data Export: single-group XLS and all-group XLS export for offline analysis

4. Formula Engine — No More Manual Calculation

This is the core capability of the custom data module. The system has a built-in flexible formula engine that lets engineers define data columns like they would in Excel, with the system automatically extracting and computing from massive sensor datasets.

4.1 Sensor Reference Syntax

4.2 Default Column Definitions + One-Click Smart Fill

The system comes with 9 standard data columns covering common temperature control indicators:

A single click on "Smart Fill" automatically matches sensor references by keyword and populates all formulas — no manual entry of lengthy sensor IDs needed.

4.3 24-Hour Lookback (Core of Cooling Rate Calculation)

Cooling rate requires comparing current values against 24-hour-ago values. The B-suffix reference (e.g., TG01B04) enables this:

• Query each device's latest data timestamp (IDATETIME field), backtrack 24 hours
• Find the closest matching record in the per-device PostgreSQL table
• Inject the result into the formula engine, replacing B-suffix references for final computation

This design ensures cooling rate calculation doesn't require continuous 24-hour data — even with communication gaps (offline catch-up), the system finds the nearest valid data point approximately 24 hours ago.

5. C5-9 Standard Report — The Key Deliverable for Final Acceptance

C5-9 is the most critical deliverable in mass concrete temperature monitoring. It is the Mass Concrete Temperature Monitoring Record Form specified in GB 50496 Appendix, which must be signed and archived during supervisor acceptance. We have fully implemented automatic generation of this form.

5.1 Report Structure

5.2 Report Configuration Tool

• Multi-Definition Management: multiple report definitions per project (different pour locations, curing methods), independently managed
• Date Range + Aggregation + Step: select any time range; raw/hourly/daily aggregation; step N to skip rows (e.g., 1 row per 4h for printing)
• C5-9 Preview API: POST /api/custom-data/c59-preview, returns fully populated data rows
• Dedicated Display Page: /custom-data/c59-report, A4 print-optimized layout, UI controls hidden by default

5.3 Export Capabilities

6. Data Reliability and Integrity Assurance

Data quality is the foundation of data analysis. The TG system ensures reliability at three levels:

7. Report System Backend Design Highlights

The report system backend (custom_data.py, ~1455 lines) is one of the most complex modules in the platform. Key technical decisions:

7.1 PostgreSQL Config Storage + JSON Serialization

User-customized data (report configs, chart headers, alarm rules) are stored as JSON in PostgreSQL JSONB columns:

• Flexible schema — no ALTER TABLE needed (each user's column definitions may differ)
• JSON passes directly between frontend and backend without extra serialization
• Centralized PostgreSQL deployment — single database manages all project data, with master-slave replication and automated backups

7.2 Multi-Database Joint Queries

A single report may span multiple TG devices whose data stored in the same PostgreSQL database (partitioned by device SN). The system uses UNION ALL or cross-table JOINs for direct joint queries — no ATTACH/DETACH needed, with native concurrency support.

7.3 Aggregation Query Optimization

For large time-span history chart queries (e.g., 30 days), querying raw data returns tens of thousands of rows, causing frontend rendering lag. The backend performs aggregation at the SQL layer before returning data.

-- Hourly average aggregation (per sensor channel)
SELECT strftime('%Y-%m-%d %H:00:00',
       REPLACE(IDATETIME, '#', '')) as dt_hour,
       AVG(WD01), AVG(WD02), ..., AVG(WD32)
FROM sheet1
WHERE dt_hour BETWEEN ? AND ?
GROUP BY dt_hour
ORDER BY dt_hour

This mechanism reduces frontend rendering from tens of thousands of rows to at most 720 (30 days × 24 hours), cutting chart load time from 5 seconds to 500ms.