3. 硬件设备选型与通信协议

数字工地现场看板的数据源头来自部署在工地各区域的传感器与采集终端。本章将系统讲解常用工地传感器的选型要点、设备数据采集原理、MQTT 通信协议的核心机制,以及 JSON 数据格式的定义规范,为后续的数据接入与可视化看板开发奠定基础。

3.1 常用工地传感器选型

工地环境监测通常关注温湿度、颗粒物浓度、噪声和定位信息。下表列出四类核心传感器的典型参数与选型建议:

传感器类型 测量范围 精度 输出接口 典型型号 适用场景
温湿度 -20~60°C / 0~100%RH ±0.3°C / ±2%RH I²C / 数字单总线 SHT30 / DHT22 材料仓库、混凝土养护区
PM2.5 0~1000 µg/m³ ±10% @ 100µg/m³ UART / PWM PMS5003 / SDS011 土方作业区、道路扬尘监测
噪声 30~130 dB ±1.5 dB 模拟量 / I²S ICS-43434 / MAX9814 打桩区、混凝土搅拌站
GPS 定位精度 2.5m CEP 冷启动 < 35s UART (NMEA 0183) NEO-6M / L76K 移动设备定位、车辆轨迹
选型避坑: 工地环境粉尘大、温湿度变化剧烈,传感器防护等级至少需 IP65。PM2.5 传感器需定期清理风扇进气口,否则数据漂移严重。GPS 天线应避开塔吊金属遮挡,优先选用陶瓷有源天线。

3.2 设备数据采集原理

数据采集链路通常分为三个层级:感知层(传感器原始信号)→ 边缘层(MCU 或 DTU 进行模数转换与初步处理)→ 传输层(通过通信协议上发至平台)。

以温湿度采集为例,典型流程如下:

  1. 传感器上电初始化:MCU 通过 I²C 或单总线发送配置指令,设置采样率与分辨率。
  2. 触发测量:MCU 发送测量命令,传感器进入转换状态(典型耗时 10~100ms)。
  3. 读取原始数据:MCU 读取传感器寄存器中的原始二进制值(如 16 位整数)。
  4. 工程值换算:根据传感器数据手册的公式将原始值转换为物理量。例如 SHT30 温度换算公式:T = -45 + 175 × (raw_value / 65535)。
  5. 数据打包:将工程值、设备 ID、时间戳按 JSON 格式组装,准备发送。
采集周期建议: 温湿度每 30~60 秒采集一次;PM2.5 和噪声建议 10~15 秒;GPS 定位按需触发,移动设备每 5 秒上报一次,固定设备可延长至 60 秒。过高的采集频率会加速传感器老化并增加功耗。

3.3 MQTT 协议详解

MQTT(Message Queuing Telemetry Transport)是物联网领域最主流的轻量级发布/订阅协议,专为低带宽、高延迟、不可靠网络环境设计。其核心机制如下:

  • 发布/订阅模型:设备(Publisher)将消息发送到 Broker,订阅者(Subscriber)从 Broker 接收感兴趣的主题消息,实现解耦。
  • 主题(Topic):采用层级结构,例如 site/001/sensor/temperature,支持通配符 +(单层)和 #(多层)。
  • 服务质量(QoS):三个等级——QoS 0(最多一次)、QoS 1(至少一次)、QoS 2(恰好一次)。工地场景推荐 QoS 1,兼顾可靠性与网络开销。
  • 遗嘱消息(Will Message):设备异常离线时,Broker 自动发布预设遗嘱,便于平台感知设备掉线。
  • 保留消息(Retained Message):新订阅者上线后立即收到 Broker 保留的最新消息,适合获取设备最新状态。

以下是一个 ESP32 设备通过 MQTT 上报温湿度数据的 Python 示例(使用 MicroPython 的 umqtt 库):

from umqtt.simple import MQTTClient
import network
import time

# 连接 Wi-Fi
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('工地WiFi', 'password')
while not wlan.isconnected():
    time.sleep(0.5)

# MQTT 连接配置
BROKER = '192.168.1.100'
CLIENT_ID = 'sensor_temp_001'
TOPIC = 'site/001/sensor/temperature'

client = MQTTClient(CLIENT_ID, BROKER)
client.connect()

# 模拟采集并发布
while True:
    temp = read_temperature()  # 假设已实现传感器读取函数
    payload = '{"device":"temp_001","value":%.1f,"unit":"°C"}' % temp
    client.publish(TOPIC, payload, qos=1)
    time.sleep(30)
安全提醒: 工地 MQTT Broker 必须启用用户名/密码认证,并建议使用 TLS/SSL 加密传输。避免在代码中硬编码凭证,推荐使用安全元件或环境变量管理密钥。

3.4 JSON 数据格式定义

JSON(JavaScript Object Notation)是设备与平台之间最通用的数据交换格式。工地传感器数据需遵循统一的 JSON Schema,确保平台解析一致。以下为推荐的通用数据模型:

{
  "deviceId": "sensor_pm_003",
  "type": "PM2.5",
  "timestamp": "2025-03-15T14:30:00+08:00",
  "value": 85.2,
  "unit": "µg/m³",
  "quality": "normal",
  "location": {
    "lat": 31.2304,
    "lng": 121.4737
  },
  "metadata": {
    "firmware": "v2.1.0",
    "battery": 78
  }
}

字段定义说明:

字段 类型 必填 说明
deviceId string 是 设备唯一标识,建议使用 MAC 地址或 UUID
type string 是 传感器类型:temperature / humidity / PM2.5 / noise / GPS
timestamp string (ISO 8601) 是 采集时间,含时区偏移
value number 是 测量数值,GPS 类型时可为 null
unit string 是 物理单位:°C / %RH / µg/m³ / dB
quality string 否 数据质量标记:normal / warning / error
location object 否 GPS 坐标,固定设备可省略
metadata object 否 设备状态扩展信息
数据压缩建议: 对于大批量上报场景,可将字段名缩写为单字母(如 d 代替 deviceId),减少传输字节。平台端再做字段映射还原。例如:{"d":"s1","t":"temp","v":25.3,"u":"°C"}。

3.5 整体架构与数据流

下图展示了从工地传感器到看板平台的完整数据链路,涵盖设备选型、采集、传输与格式转换:

数字工地数据采集与传输架构 感知层 温湿度传感器 PM2.5 传感器 噪声传感器 GPS 模块 I²C / UART / 模拟量 边缘层 MCU / DTU 数据采集与缓存 工程值换算 JSON 打包 传输层 MQTT Broker 主题路由 QoS 保障 TLS 加密 平台层 数据 解析 存储 看板 告警 数据流说明 1. 传感器通过 I²C/UART 等接口将原始信号传输至边缘 MCU/DTU。 2. 边缘设备完成模数转换、工程值换算,并按统一 JSON Schema 打包数据。 3. 边缘设备作为 MQTT 客户端,将 JSON 消息发布到 Broker 的指定主题。 4. Broker 根据主题将消息推送给已订阅的平台后端服务。 5. 平台解析 JSON,存入时序数据库,并驱动实时看板与告警引擎。 关键协议:MQTT v3.1.1 / v5.0 | 数据格式:JSON (UTF-8) | 传输加密:TLS 1.2+

3.6 通信协议选型对比

除 MQTT 外,工地场景还可能涉及其他协议。下表对比了三种常见协议的适用场景:

协议 传输模型 带宽消耗 实时性 适用场景
MQTT 发布/订阅 低(最小 2 字节头部) 高(秒级) 传感器数据上报、远程控制指令
CoAP 请求/响应(类 HTTP) 极低(基于 UDP) 中(需重传机制) 资源受限设备、低功耗场景
HTTP/HTTPS 请求/响应 高(头部开销大) 中(轮询延迟) 配置下发、固件升级、非实时数据查询
推荐组合: 实时传感器数据采用 MQTT + QoS 1;设备配置下发与固件升级使用 HTTPS;低功耗电池供电设备可考虑 CoAP 以延长续航。三种协议可在同一网关内共存,通过协议转换模块统一接入平台。