Brownfield 改造最容易制造一种错觉：Modbus 寄存器能读、OPC UA 节点能订阅、旧 CSV 能上传，项目就已经完成了最难的一半。实际上，采集链路只证明字节从现场到达了平台，并没有证明这些字节代表正确设备、正确单位、正确时间和可用状态。只要其中一个条件缺失，同一条数据在趋势图里可能看起来连续，却会把告警、能耗报表和预测模型推向错误结论。
本文复盘一个可重复运行的实验案例。我们构造了 20 条来自 Modbus、OPC UA 和旧文件接口的遥测记录，再用确定性脚本检查身份、单位、范围、时间、采样周期和质量码。脚本只接纳了 8 条，另外 12 条进入隔离；这个 40% 接纳率不是任何工厂的缺陷率，而是专门设计的脏数据 fixture 产生的实验结果。真正值得复用的结论是：Brownfield 项目必须把“可采集”和“可消费”拆成两道独立 Gate，并让失败记录保留来源、原因和重放路径。
1. 场景约束：三种接口接通了，但没有共同的数据合同
实验把一个典型老旧现场压缩成三个来源。空压机压力来自 Modbus 寄存器，炉温来自 OPC UA 节点，配电能耗则由旧系统按分钟导出。三条链路的更新周期、时间来源和质量表达方式都不同：Modbus 原始值通常不自带工程单位和采集时间，OPC UA DataValue 可以携带 StatusCode、sourceTimestamp 与 serverTimestamp，旧文件接口则可能只有操作员维护的列名和导出时间。
如果平台只要求 value + timestamp，这些差异会在接入层被抹平。结果不是“数据统一了”，而是来源证据丢了。压力值 6.9 究竟是 bar 还是 kPa、炉温时间来自 PLC 还是网关、同名点位属于哪台设备，都会在下游变成猜测。对于告警和状态计算，猜测的代价不是报表不够漂亮，而是错误阈值、错误资产和错误时间窗口被当成事实。
因此，实验先为每个来源定义最小合同：固定的 source_key、预期 asset_id、canonical metric、工程单位、合理范围和采样周期。合同没有尝试解决所有语义问题，只回答一条记录是否具备进入可信状态层的最低条件。更完整的链路分层可参考工业遥测数据链路怎么分层，Tag 身份和语义合同则见工业 Tag 模型不是点位表。
2. 审计结果：20 条记录中，12 条需要隔离而不是自动修正
本地审计脚本逐行读取 fixture，并对九类问题计数。实际结果是 20 条记录中 8 条直接接纳，12 条进入隔离；隔离记录共触发 14 个问题，因为同一条记录可能同时缺值并携带非 Good 质量码，或者单位错误并越过合理范围。
| 检查项 | 触发次数 | 为什么不能静默修正 |
|---|---|---|
| 缺失值 | 2 | null 可能是通讯失败、设备停机或导出缺列，不能统一补零 |
| 单位不一致 | 2 | bar、kPa、F 和 C 的转换需要来源与版本证据 |
| 越界值 | 2 | 可能是真实异常，也可能是单位或寄存器映射错误 |
| 采样间隔缺口 | 2 | 影响窗口统计、变化率和事件顺序 |
| 质量码非 Good | 2 | 值仍存在不代表它可用于控制或告警 |
| 时钟偏差 | 1 | 网关接收时间不能替代源时间回答事件先后 |
| 资产映射错误 | 1 | 正确数值写到错误设备，比缺值更难发现 |
| 重复时间戳 | 1 | 需要幂等键和冲突规则，不能按到达顺序覆盖 |
| 未知来源 | 1 | 未经准入的点位不能自动成为正式 Tag |
这张表之后最重要的判断不是“规则越多越好”。如果系统在接入时把 bar 自动乘以 100，把缺失值自动补成上一次值，再把未知来源按名称相似度绑定资产，短期报表会更完整，但证据链会被破坏。Brownfield 数据治理应优先保留原始值和失败原因，让修复成为版本化、可审核的决定，而不是不可见的数据清洗副作用。
正文图：质量隔离台账把来源、单位、时间、质量和资产映射并列核对，强调“拒绝原因可追溯”而不是自动美化数据。
3. 根因复盘：数据质量问题沿着身份、数值和时间三个方向扩散
3.1 身份错误会把正确数值写进错误资产
实验中有一条压力记录的来源仍是 modbus-1/40001，但资产从 compressor-07 变成了 compressor-08。如果平台只按目标资产写入，这条记录在范围和单位上都“正常”，却会污染另一台空压机的历史。身份错误通常来自点位表复制、PLC 改址、网关模板复用或资产更名，它比通信中断更危险，因为下游看不到明显空洞。
治理动作应把来源地址、canonical metric 和资产绑定分开保存，并给绑定关系单独版本。自动发现可以提出候选，不能覆盖已确认映射。发生冲突时，系统应保留原始 source_key 并隔离，而不是选择最近匹配的名称。这会增加人工确认工作，但避免历史状态被悄悄改写。
3.2 单位和范围必须联合判断，单独转换会掩盖根因
fixture 同时放入 6.9 bar 的压力与 363.5 F 的炉温。两者都可以数学转换，但平台不知道设备是否真的改变了工程单位、网关模板是否错选，或者操作员是否只改了列头。单位变化若没有映射版本和生效时间，直接转换会让历史数据看似连续，却无法解释阈值为什么在某一刻改变。
范围检查也不能独立做最终裁决。炉温 356 C 超过实验合同的 300 C 上限，它可能是传感器异常，也可能是工艺真实越界；系统可以阻止它推进“当前可信状态”，却不应删除原始记录。正确做法是把原始流、隔离流和可信状态层分开：原始流保存事实，隔离流承载待确认问题，可信状态层只接受满足合同的版本。
3.3 时间质量决定数据能否参与窗口、顺序和因果判断
一条炉温记录的源时间与网关时间相差 32 秒，另一条记录重复使用同一个源时间戳。对日汇总而言，32 秒可能无关紧要；对十秒采样的变化率、告警持续时间和设备联锁分析而言，它足以改变事件顺序。时间质量不能只用一个 timestamp 字段表示，至少要区分源时间、接收时间和平台处理时间，并记录哪个时钟生成了它。
OPC UA 对 sourceTimestamp、serverTimestamp 和 StatusCode 的区分说明了同一数值需要伴随可用性与时间语义。Sparkplug 也要求数据 Metric 携带 UTC 时间，并在 BIRTH 消息中定义名称、alias 与 datatype。把这些字段压成一个浮点值和一个服务器时间，会让协议层提供的质量证据在进入平台前就丢失。
4. 实施：把质量 Gate 放在可信状态之前，而不是报表之后
质量检查最迟应发生在数据推进设备状态、告警和报表之前。原始记录先进入可回放区，再根据当前合同执行观测；通过的记录写入可信状态与下游主题，失败的记录携带规则版本、原因码和原始载荷进入隔离。这个顺序允许团队修改规则后重放历史，却不会让一次修复自动篡改已发布结果。
flowchart LR
A("原始采集记录"):::blue --> B("质量观测"):::cyan
B -->|合同通过| C("可信状态与数据产品"):::green
B -->|身份、单位、时间或质量失败| D("隔离流"):::orange
D --> E("责任人确认根因"):::violet
E --> F("版本化映射或规则"):::slate
F --> G("影子重放与差异检查"):::cyan
G -->|通过| H("批准发布"):::green
G -->|仍不确定| D
H --> B
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
这条闭环里，“自动修复”只适合证据充分且可逆的情况。例如，来源合同明确规定原始寄存器始终以 0.1 kPa 缩放，转换规则经过版本化验证后可以自动执行；如果单位变化来自操作员临时改表，系统就没有足够证据直接改写。不能解释来源和生效时间的转换，即使数值看起来合理，也应继续留在隔离区。
5. 责任与指标：质量问题必须有所有者，不能只剩一个总分
一个“数据质量 92 分”的仪表盘无法告诉团队谁该行动。更可执行的做法是按数据产品和质量维度分开观察：采集团队负责通讯成功率和接收延迟，设备或工艺负责人确认单位与合理范围，资产治理负责人维护 source-to-asset 映射，平台团队保证规则版本、隔离积压和重放结果可审计。所有者不同，问题的关闭证据也不同。
上线时至少要保留接纳率、隔离率、未知来源数、映射冲突数、单位冲突数、源时间偏差分位数、超期未更新 Tag 数量和隔离记录年龄。接纳率上升本身不是成功：如果团队通过关闭规则让接纳率变高，可信度反而下降。更稳妥的组合是同时看隔离原因的关闭时间、修复后重放差异，以及下游告警和报表是否重新通过验收。
告警也不应直接消费所有“有数值”的记录。非 Good 质量、超期未更新或映射待确认的记录可以生成数据质量事件，却不应和真实工艺异常混成一个告警生命周期。有关事件事实、告警 episode 与人员处置的边界，可参考工业 IoT 的告警和事件为什么不能混着建模。
6. 实验结果能证明什么，也不能证明什么
本次脚本重复执行会得到同一个结果：20 条输入、8 条接纳、12 条隔离，九类检查均有确定计数。这证明最小合同能够在 fixture 上阻止明显不可信记录进入状态层，也证明一条记录可以同时触发多个质量维度。它还提供了一个可复查的基线：以后修改规则时，可以比较隔离集合，而不是只看“脚本跑通”。
但实验没有连接真实 PLC、网关、消息总线或时序数据库，也没有模拟网络抖动、设备重启、补传洪峰和规则热更新。40% 接纳率不能外推为生产缺陷率，5 秒时钟偏差阈值和 1.5 倍采样间隔也不是通用标准。真实项目必须由工艺窗口、告警语义、采样方式和数据消费 SLA 决定阈值，并在影子流量中验证误隔离与漏隔离。
生产验收还需要把“规则能识别 fixture”与“系统能持续治理现场数据”分开。前者由确定性测试证明，后者必须观察规则变更后的隔离积压、重放耗时、责任人关闭时长，以及修复前后告警和报表的差异。缺少这些运行证据时，测试通过只能允许进入影子验证，不能直接批准全量数据产品发布。
ISO 8000-61 把数据质量管理视为持续过程，而不是一次清洗；NIST 关于制造数据收集、整理和复用的建议也强调标准、上下文和可重复使用。对 Brownfield 现场，这意味着上线定义不应是“所有设备都有数据”，而应是“关键数据产品有明确合同、责任人、隔离路径、重放证据和可接受的质量 SLO”。
7. 什么时候只做边缘规则，什么时候需要平台治理
如果现场只有少量固定设备，单位和映射多年不变，数据只用于本地显示，而且发生错误时由同一个班组处理，那么边缘网关里的显式校验、原始日志和人工点位表可能已经足够。为了一个几十点的封闭系统引入中央规则注册、隔离队列和审批流，会制造超过收益的维护成本。
当同一来源要被告警、能耗、预测维护和跨厂报表共同消费，或者设备映射、单位、固件和采样策略会持续变化时，质量规则就必须成为平台合同。此时缺少版本、所有者和重放能力，会让每个下游团队各自清洗一遍，最终得到互相冲突的“真相”。平台化的价值不是多一张质量大屏，而是让同一修复可以被解释、验证、发布和回滚。
结论：先定义可消费，再扩大可采集
Brownfield 工业数据治理的第一目标，不是让每个点位尽快出现在大屏上，而是让关键数据在进入状态、告警和分析之前具备身份、单位、时间、质量和版本证据。采集成功只回答“有没有收到”；质量合同才回答“能不能用、用于什么、出错后怎么恢复”。
把原始流、隔离流和可信状态分开，会增加规则维护、人工确认和重放验证的成本，但它把隐蔽的数据污染变成可见、可分配、可回滚的问题。对于需要长期运行和跨系统复用的工业平台，这个成本通常比事后解释错误告警、错误能耗和错误模型便宜得多。
参考资料
- OPC Foundation — OPC UA Part 4, DataValue
- Eclipse Foundation — Sparkplug Specification 3.0.0
- ISO 8000-61:2016 — Data quality management process reference model
- NIST — Recommendations for Collecting, Curating, and Re-Using Manufacturing Data
- NIST — Foundations of Information Governance for Smart Manufacturing
