当 AI 成为数据的第一用户，工业物联底座该怎么重构
一句话判断：AI 不缺数据，缺的是说得清出处的数据。
副标题：解绑测点 · 数据带出身 · 模型可仲裁
AI 成为数据的第一用户，工业物联底座该怎么重构？老系统真正的短板不是运行时，是数据模型：测点绑死设备，值说不清出处。本文以一套运行二十年的工业物联底座重构为样本，给出三刀——测点解绑、数据自带出身、声明式模型让 AI 产出可校验可仲裁，并说明端云如何共用一套契约、以及不做大爆炸式替换的四关推进路线。让现场数据被看见、被相信、被用好。
本文要点
- 老底座最该改的不是操作系统或开发语言，而是数据模型：业务测点被死死挂在设备名下，设备一换，点就断。
- 「AI 原生」不是加一个大模型接口，而是回答三问：语义、时间与质量、血缘。判据是产出能否被机器校验。
- 第一刀用「五件套」把测点从设备上解下来，业务树与设备树通过
SourceBinding关联；第二刀让每条Observation自带出身；第三刀把组态变成可 diff、可回滚的声明式模型。 - 端云同一契约、各自实现；落地走「立基线 → 铸内核 → 长能力 → 过交付」四关，而不是一次性替换。
0. 引言：如果只许改一件事，改什么？
我与设备打了二十多年交道。最近这段时间，我一直在琢磨这套底座 3.0 的重构：嵌入式端从 .NET Micro Framework 迁到 RT-Thread + MicroPython，实时数据库 IODB 重新设计，点表要撑起从单台网关到整个集团的数据。
动手之前，我给自己出了一道题：如果只许改一件事，改什么？
换操作系统？换开发语言？把组态搬到网页上？想来想去，这些都对，但都没说到根上。这次重构真正要回答的问题是——
在 AI 成为数据第一用户的年代，一个做了二十年的工业物联底座，应该长成什么样？
1. 二十年老底座，为什么要动
2001 年我进工控行业，最早做的是计量监控、烧结配水、焦炉机车这一类系统。后来做组态后台，再到 YFIOs——驱动、策略、实时数据库 IODB、大块数据 IOBC 各司其职：驱动管通信，策略管逻辑，IODB 管点数据交换。这套架构用了十几年，跨过了 WinCE、.NET Micro Framework 一个又一个平台。
但今天它确实老了。老在三个地方。
1.1 三处老化
| 维度 | 现状 | 后果 |
|---|---|---|
| 运行时 | NETMF 已停止演进，社区萎缩 | 新硬件接不上，招人越来越难 |
| 组态方式 | Windows 桌面工具 + USB 线逐台下载 | 现场早已习惯打开浏览器就能干活 |
| 数据模型 | 业务测点挂在设备名下 | 设备一换，点就断；历史、报警、画面全要重配 |
前两处是工程问题，第三处是模型问题。工程问题可以换技术栈解决，模型问题会一直跟着你。
1.2 一个空压机站的例子
工厂的空压机站，现场需要「3# 空压机排气压力」和「3# 空压机电机绕组温度」。这两路数据由网关 G1 下的子设备采，还是由网关 G2 直接采，从业务上看有区别吗？
没有。压力就是那路压力，温度就是那路温度。
只有设备出了问题、要维护了，我们才关心它当时从哪个网关、哪个寄存器来。可过去的系统，把业务测点死死挂在了设备名下——设备一换，点就断，历史曲线断在半空中，报警规则要重配，前端画面要改引用。
第一性原理：设备会换，测点不应换；连接会断，历史不应断。
这是我这半年想得最多的一句话，也是这次重构的起点。
2. 什么叫 AI 原生：先看 AI 怎么「死」在老系统上
这两年 AI coding 火得一塌糊涂，我们也在用 AI 生成组态、生成接入代码、生成数据分析。但真用起来就明白一个道理：
让 AI 生成东西不难，难的是验证它生成得对不对。
DORA 2026 报告把这叫「验证税」——生成越便宜，验证越贵。工业现场更是如此：99% 的成功率不叫可靠性，叫灾难。
2.1 老 IODB 的一个点，AI 答不上来
我拿老 IODB 里的一个点问 AI：「3# 空压机的排气压力现在可信吗？」AI 一看，傻眼了：
| AI 的疑问 | 老 IODB 现状 | 3.0 的解法 |
|---|---|---|
| 这个值是什么类型、什么单位？ | 字符串存的 "0.78"，类型不明确 |
Measurement 声明单位、量程、精度 |
| 这条值可信吗？ | 无质量码，分不清是通信成功读来的还是超时残留的旧值 | Good / Uncertain / Bad + 细分原因 |
| 到底是什么时候测的？ | 只有一个时间戳，说不清是设备测量时刻还是网关收到时刻 | 设备 / 网关 / 云端三时间戳 + 「边缘估算」标记 |
| 数据从哪来的？ | 点表挂在某台设备名下，查血缘要人肉翻配置 | binding_id 轻量携带，可反查 |
核心判断：AI 不是缺数据，是缺说得清出处的数据。没有语义、时间、质量、血缘的数据，喂给模型的就是一堆看似丰富、实则无法解释的数字。
2.2 AI 原生的三个判据
所以「AI 原生」不是给老系统加一个大模型接口，而是反过来问三个问题：
- Q1 语义：AI 读这条数据时，知不知道它的单位、量程、含义？
- Q2 时间与质量：AI 相不相信这条数据？
- Q3 血缘：AI 追溯这条数据时，能不能找到它从哪个设备、哪次采集来？
这三个问题，决定了 3.0 整个数据模型的形状。它们同时也是判断一套工业数据系统「是否 AI 就绪」的可执行 checklist。
3. 第一刀：把测点从设备上解下来
重构的第一刀，砍在模型层级上。
旧：网关 → 子设备 → 变量 → 云端数据
业务数据是设备树的叶子，随设备一起被替换
新：Measurement（业务树，永久身份）
↑ SourceBinding（来源 / 换算 / 优先级 / 生效时间 / 映射版本）
RawTag（设备树，某个时期的数据生产者）
过去业务数据是设备的附属品；现在倒过来：测点是业务资产，设备只是某个时期的数据生产者。
3.1 五个核心对象（「五件套」）
| 对象 | 职责 | 关键内容与归属 |
|---|---|---|
Measurement |
业务测点，永久身份 | 单位、量程、精度、有效期、报警策略；按业务树组织，不随设备走 |
RawTag |
设备侧原始变量 | 寄存器地址、OPC UA NodeId、本地 ADC；握手位与诊断量留在此层，不必都上云 |
SourceBinding |
采集绑定 | 来源、换算、优先级、生效时间、映射版本；换设备换的是 Binding |
Observation |
观测样本 | 值、质量码、三时间戳、序号、血缘标识 |
ProducerHealth |
生产者健康 | 在线状态、时延、成功率；归运维，不再绑架业务数据 |
 |
3.2 工程验证：一座抽水蓄能电站给出的答案
这不是纸上推演。前几年我们给南方某大型抽水蓄能电站做大坝水工监测改造，四百多个测点，散布在上库、下库、地下厂房、蜗壳、岩锚梁。仪器五花八门：差阻式、振弦式、电容式，还有 4~20mA 标准信号；采集器也分成差阻、振弦、电容、模拟量好几种，各管一摊。
最有意思的是，每支仪器测出来的先是「原始量」——电阻比、频差、电容比，要靠一套标定公式才能变成工程量：电阻比变温度，频率变应力，电容比变位移。公式里的标定参数 A、k、f0、R0，每支仪器都不一样。
这件事让我把 Binding 想得更透：
「原始量 → 公式 → 工程量」的换算，天然属于绑定，不属于测点身份。
仪器坏了一支、换了一支，换的是公式参数，「蜗壳钢筋应力」还是那个测点。工业现场最土、最真实的工程实践，和我们要建的模型，说的是同一件事。
3.3 双树模型与故障切换
云端因此有两条树：
- 业务树回答「我要看什么」，按集团、厂区、区域、对象组织；
- 设备树回答「数据从哪来、去哪修」，按项目、网关、子设备组织。
两棵树通过 Binding 关联，互不绑架。G1 离线了？产生一条采集事件，检查备用路由 G2 有没有新鲜数据，有就无缝切换血缘；都没有，最后值保留、按测点自己的 TTL 转为「陈旧」——而不是 500 个点齐刷刷报 500 条「数据不可靠」的报警风暴。
4. 第二刀：让每条数据自己会说话
第二刀砍在数据本身上。新 Observation 里，每条样本都带齐了四样东西。
| 要素 | 内容 | 解决什么 |
|---|---|---|
| 三个时间戳 | 设备测量时刻、网关接收时刻、云端接收时刻 | 哪一段延迟、哪一段时钟不可信一目了然；设备无准确时间由网关标注「边缘估算」，不装诚实 |
| 质量码 | Good / Uncertain / Bad + 超时、超量程、人工置值、估算值等细分原因 |
区分「读到」与「残留」；OPC UA 数据可带原始 StatusCode |
| 序号 | boot_id + seq |
重启不乱、同毫秒可辨、重复可去重；历史库幂等键不再是「点名 + 时间戳」 |
| 血缘 | binding_id 轻量携带 |
一段数据异常，可反查当时是哪个网关、哪个绑定在供数 |
下面是一个示意性的样本契约（字段用于说明模型形状，非最终 API）：
{
"measurement_id": "plant-a.comp-03.discharge_pressure",
"value": 0.78,
"unit": "MPa",
"quality": "Good",
"quality_reason": null,
"ts_device": "2026-11-12T09:58:32.120+08:00",
"ts_gateway": "2026-11-12T09:58:32.340+08:00",
"ts_cloud": "2026-11-12T09:58:32.512+08:00",
"time_origin": "device_clock",
"boot_id": "gw1-20261109-0001",
"seq": 184672,
"binding_id": "bind-v3-g1-40021"
}
4.1 一个容易踩的坑：样本质量不可变，当前有效性动态算
设备后来离线了，不能回头把历史数据改写成 Bad——历史是历史。最新值还能不能用，由「距离测量时刻多久 + 当前绑定健康 + 该测点自己的有效期」实时算出来。温度可以容忍一分钟，振动 200 毫秒就算陈旧，所以有效期属于测点，不属于设备。
定点采集也是同理。那座电站的四百多个测点，绝大多数一天采一次，关键部位一小时一次，还有「每七天加密一天、按小时采集」的策略。大坝是慢数据，振动是快数据——采集频次和有效期，天生就是测点自己的策略，不该由系统一刀切。
4.2 前端不再显示一个裸数字
过去画面上是一个 65.2，现在应该是：
65.2 ℃，采集于 09:58:32，已陈旧 75 秒，当前路由中断
宁可承认不可知，不能伪装成新鲜。
5. 第三刀：让模型可验证、可仲裁
第三刀砍在「配置」上，也是 AI 原生最直接的落点。
AI 生成什么东西最好验证？声明式的模型文件，而不是命令式的代码。
| 生成物 | 可校验手段 | 出错成本 |
|---|---|---|
| 声明式点表 / 物模型（JSON） | Schema 校验、逐字段 diff、回滚、终端模拟器仿真 | 机器和人都能看出错 |
| 命令式代码 | 基本只剩「读一遍」 | 全额缴纳验证税 |
一份点表定义、一份物模型，本质就是 JSON。下面同样是示意结构：
{
"measurement": {
"id": "plant-a.comp-03.discharge_pressure",
"name": "3# 空压机排气压力",
"unit": "MPa",
"range": [0, 1.6],
"precision": 0.01,
"ttl_seconds": 60
},
"bindings": [
{
"binding_id": "bind-v3-g1-40021",
"gateway": "G1",
"raw_tag": "modbus://G1/40021",
"formula": "raw * 0.001",
"priority": 10,
"version": 3
},
{
"binding_id": "bind-v3-g2-40021",
"gateway": "G2",
"priority": 20,
"version": 3
}
]
}
5.1 组态链路
AI 读公开契约
→ 生成声明式点表 / 物模型（JSON）
→ Schema 校验 + 逐字段 diff + 终端模拟器仿真
→ 人确认
→ 原子发布（生成新模型版本），可回滚
旁路：USB 仅用于首次烧录与无网恢复，不再是唯一配置入口
设备 Web 端做草稿、校验、编译、发布、回滚；每次发布生成新的模型版本。
我在上一篇《从点表到物模型，再到「模型即数据」》里说过：在 AI 时代，协议文档不再是给工程师看的手册，而是给 AI 读的规格面。 数据契约继续公开——AI 有抓手，产出才可仲裁。
6. 端和云：同一契约，各自实现
模型定了，端和云怎么落？
| 嵌入式端 | 云端 | |
|---|---|---|
| 实时内核 | C/C++ 守住驱动、IODB、报警、时间、通信 | — |
| 扩展层 | MicroPython 做策略、计算点、非硬实时扩展 | 视图与订阅 API |
| 存储 | IODB 冷热分离：定义放 Flash，运行态放 RAM | 逻辑一张表、物理多平面：定义目录、最新状态、历史时序、报警事件、搜索索引、对象与分析 |
| 部署形态 | 新硬件起步，RT-Thread + MicroPython | 小项目单 Broker + 单库；大项目分区、集群、数据湖按需长出来 |
| 明确禁忌 | 不让 Python 字典当实时数据库，不在高频采集循环里反复造字符串；三十多个字段全塞内存不是通用性，是浪费 | 前端只拿视图和订阅，不扫全表 |
RT-Thread + MicroPython 是手段不是目的。同一套模型，不是同一套重型部署：小项目方便用，大项目能支撑，靠的正是逻辑统一与物理解耦。
至于 AI 怎么用这些数据——通过授权的只读语义查询，问「3# 空压机排气压力现在多少、新不新鲜、上周为什么异常」；训练数据走对象存储和 Parquet。AI 不直接碰底层大表，更不绕过权限去碰设备。
数据越开放，边界越要清楚。
7. 重构不是一次替换，是一条可验证的路
不做大爆炸式替换：老 NETMF 产品继续维护，新平台从新硬件、一个典型 Modbus 项目起步，新旧对照跑黄金帧测试。
| 关口 | 目标 | 验收判据 |
|---|---|---|
| 一、立基线 | 冻结旧配置导入、典型驱动黄金帧 | 新旧输出逐帧可比 |
| 二、铸内核 | C 版 IODB、三时间戳、质量码、序号 | 断链后不再继续上报「新鲜的 Good 值」 |
| 三、长能力 | MicroPython、报警状态机、持久化续传、只读 Web | 断网续传后历史幂等、不重复 |
| 四、过交付 | Web 原子部署、模型注册、OPC UA 与 Modbus 投影 | 可 diff、可回滚；之后才谈数据湖与 AI |
这条路看着比直接换个运行时慢，实际是在减少未来十年的返工。
8. 写在最后
写到这，想起当年从 DOS 转 Windows 时的失落，也想起后来 TinyGUI 的积累在嵌入式图形里重新变成稀缺品。重构一个二十年的底座，最怕的不是技术难，是忘了它为什么被造出来——让现场数据更快地被看见、被相信、被用好。
技术会变，工具会老。但让测点独立于设备、让数据带着出身行走、让 AI 有可仲裁的规格可用——这些是给未来十年打的地基。
范式会变，数据长存。
参考资料与延伸阅读
- DORA 2026 报告（文中「验证税」概念出处）
- OPC UA StatusCode 与质量码规范（观测样本质量码设计参照）
- 《从点表到物模型，再到「模型即数据」：二十年亲历，见证设备接入的范式革命》（作者前作）
关于作者
刘洪峰，叶帆科技创始人兼 CEO，物联网极客。多届微软 MVP、阿里云 / 华为云 MVP、CSDN 十大 MVB。深耕 AIoT 二十年，研发 YFIOs 数据组态、YFHMI 画面组态及近百种物联网硬件。译《.NET Gadgeteer 电子积木》，著《低代码极速物联网开发指南》，在写《AIoT 全栈开发实战：从 PCB 电路板到 AI 智能体》。践行「一叶启帆，万物智联」。
浙公网安备 33010602011771号