平台层到底要解决什么问题

把设备数据采上来只是第一步。真正的问题是：几千几万家工厂、每厂几百台设备的数据涌进平台后，怎么存、怎么查、怎么让不同角色（厂长、设备维护、质量工程师）看到各自关心的内容。工业互联网平台就是在这堆原始数据和业务应用之间，搭一层通用的“数据底座”。

平台层的价值在于“一次接入、处处复用”：设备模型、鉴权规则、告警引擎做一次，后面的每个数字工厂项目都在上面搭，而不是每个客户都从零写一遍。
工业互联网平台配图：分层云架构中心连接右侧数字工厂产线
平台层把设备接入、数据存储、业务应用分层解耦，数字工厂在上面长出来

和消费互联网平台相比，工业平台的特殊之处在于：数据量大（秒级采集、万台设备）、实时性要求高（告警要秒级送达）、租户隔离严格（客户数据绝不能串）、还要能在私有化部署和公有云两种形态下都跑。这些约束决定了它的技术选型和一般后台系统不一样。

设备接入：MQTT、CoAP 与 HTTP 选型

边缘网关把数据送上云，最常用的是 MQTT：轻量、发布订阅、支持海量长连接，一个网关断连重连成本很低。CoAP 适合资源极度受限的小设备（电池供电、几百 KB 内存），HTTP 只适合偶尔上报的设备，不适合高频采集。

接入协议怎么选
  • MQTT边缘网关、PLC 上云首选，支持 QoS 和遗嘱消息，断连可感知。
  • CoAP超小设备、NB-IoT 场景用，基于 UDP，开销极小。
  • HTTP低频、对实时性不敏感的设备（比如每天报一次），简单直接。
  • Modbus/TCP、OPC UA厂区内直接对接云端的场景，平台要内置这些服务端能力。

设备接入层要解决几个共性问题：设备身份认证（一机一密）、连接管理（在线状态、心跳超时）、消息路由（按主题分发到下游消费服务）、以及限流（一台异常网关刷爆平台要能快速掐断）。

时序数据库与数据清洗

工业数据的特点是“按时间线持续追加、很少修改”——这正是时序数据库的主场。MySQL 存这类数据会又慢又贵，InfluxDB、TimescaleDB、TDengine 这类时序库按时间分区、高压缩比，专门为秒级测点优化。

典型测点写入结构（TDengine 为例）
超级表: metrics
标签:   tenant_id, factory_id, device_id, point_code
列:     ts (时间戳), value (浮点), quality (质量码)

-- 写入
INSERT INTO metrics USING metrics TAGS ('t01','f01','dev-001','speed')
  VALUES (now, 1480.5, 0);

-- 查询某台设备最近 1 小时
SELECT ts, value FROM metrics
WHERE device_id='dev-001' AND point_code='speed'
  AND ts >= now - 1h
INTERVAL(1m) FILL(linear);

数据进时序库之前必须做清洗：去重、跳变剔除、单位归一、质量码标记。原始数据直接落库，后面看板上看到的曲线就会满是毛刺和坏点，解释起来非常麻烦。清洗逻辑放在边缘网关还是平台，取决于你对实时性的要求——简单过滤放边缘，复杂模型放平台。

微服务架构：租户、鉴权与弹性

平台层一般按业务域拆微服务：设备接入服务、时序数据服务、告警引擎、权限中心、报表服务。所有请求经过网关层统一鉴权，租户 ID 贯穿整条链路，确保 A 厂的数据永远不会被 B 厂看到。

服务职责关键技术
接入网关MQTT 连接、认证、路由EMQX / Mosquitto 集群
时序服务测点读写、聚合TDengine / InfluxDB
告警引擎规则匹配、通知推送规则引擎 + Webhook
权限中心租户、角色、设备分组OAuth2 + RBAC
报表看板趋势、OEE、能耗BI 组件 + 时序查询

弹性扩缩在工业场景不是为了应对流量洪峰，而是为了应对“某家客户突然接入一千台设备”这类事件。接入网关和时序写入要能水平扩容，状态尽量无状态化，消息队列削峰填谷。