4. 工业数据采集与集成设计

在AVEVA数字孪生运营平台中，数据采集与集成是连接物理世界与数字世界的“第一公里”。如果这一层设计不当，后续的模型映射、可视化组态、KPI计算和高级分析都会失去可靠的数据基础。本节围绕一条完整的数据链路展开：现场控制层（PLC、DCS、SCADA）→ 边缘采集层（IoT网关/AVEVA Edge）→ 中心平台层（AVEVA Data Hub / PI System / 运营平台），并重点说明OPC UA与MQTT两类协议在其中的分工与配合方式。

一、先分清四类数据源的角色差异

PLC是离散控制的主力，通常以毫秒级扫描周期运行，数据以寄存器、线圈、DB块等形式存在，适合通过OPC UA服务器或原生工业以太网协议（如S7、Modbus TCP、EtherNet/IP）暴露。DCS则面向连续过程，控制器内部已有成熟的位号体系和历史存储，通常通过OPC UA/DA或专用接口对外提供聚合数据。SCADA位于监控层，本身已是“数据汇集者”，它掌握着报警、趋势、操作记录等上下文信息，适合作为边缘侧的数据补充来源。IoT网关则承担协议转换与边缘预处理，把异构协议统一为MQTT或OPC UA，再上传至中心平台。

这四类源不是替代关系，而是分层互补：PLC/DCS提供高频原始过程量，SCADA提供工况与事件上下文，IoT网关提供协议归一化和边缘计算能力。设计时要先明确每个位号的“源归属”，避免同一测点从多个路径重复采集导致时间戳冲突。

二、OPC UA与MQTT的分工：不是二选一，而是各管一段

OPC UA的核心价值在于“语义化+安全+可靠”。它自带信息模型，可以把一个PLC变量描述为“设备/单元/位号”的层级结构，并支持订阅、方法调用、历史访问。在边缘侧，AVEVA Edge通常作为OPC UA Client去订阅PLC/DCS的OPC UA Server，或者作为OPC UA Server把聚合后的数据再暴露给上层。OPC UA适合局域网内、对确定性和语义要求高的场景。

MQTT的核心价值在于“轻量+发布订阅+弱网适应”。它基于主题（Topic）进行消息路由，天然支持一对多分发和断线重连，适合跨越广域网、带宽受限或NAT环境的场景。在AVEVA Data Hub中，MQTT Broker是流数据的入口，边缘网关以发布者身份把数据推送到指定Topic，中心平台按Topic订阅并写入时序库。

实际设计中常见的组合是：边缘侧用OPC UA采集，中心侧用MQTT上传。AVEVA Edge同时具备OPC UA Client和MQTT Client能力，可以在内部完成协议转换。这样既保留了现场语义，又获得了广域传输的灵活性。

三、数据流设计的关键参数与配置示例

下面给出一个典型的边缘采集配置片段，用于说明关键参数如何影响数据质量。示例为合理假设的教学参数，并非实测结果。

# AVEVA Edge 采集通道配置示例（教学假设）
Channel: PLC_Line1
  Protocol: OPC UA
  Endpoint: opc.tcp://192.168.10.21:4840
  SecurityPolicy: Basic256Sha256
  Subscription:
    PublishingInterval: 100ms      # 订阅发布周期
    SamplingInterval: 50ms         # 采样周期
    QueueSize: 10                  # 队列深度，防突发丢包
  Tags:
    - Name: Line1_Motor_Speed
      NodeId: ns=2;s=DB1.Speed
      Deadband: 0.5                # 死区，变化小于0.5不推送
    - Name: Line1_Temperature
      NodeId: ns=2;s=DB1.Temp
      Deadband: 0.2

# MQTT 上传配置
MQTT:
  Broker: ssl://datahub.aveva.example:8883
  ClientId: edge-gw-line1
  Topic: plant/line1/telemetry
  QoS: 1                           # 至少一次
  PublishInterval: 1000ms          # 聚合后1秒上传
  Buffer:
    MaxSize: 50000                 # 断线缓存条数
    RetryInterval: 30s

这里有两个参数最值得关注：Deadband（死区）和PublishInterval（发布周期）。死区过小会导致大量冗余数据上传，死区过大则会丢失真实的小幅波动。发布周期要与中心平台的存储策略匹配：如果中心按1秒归档，边缘却以100毫秒推送，就会造成5~10倍的无效写入。一般建议边缘聚合周期≥中心归档周期的1/2，同时保证关键报警量走独立的高优先级Topic。

四、时间戳与数据质量：最容易被忽视的两个字段

在数字孪生场景中，数据必须能回答“什么时候的值”和“这个值可不可信”。因此每个上传的数据点至少应携带：源时间戳（SourceTimestamp）、服务器时间戳（ServerTimestamp）、质量码（Quality）和采集通道标识。OPC UA原生支持这些字段；MQTT传输时需要在Payload中显式定义JSON结构，例如：

{
  "tag": "Line1_Motor_Speed",
  "value": 1480.5,
  "unit": "rpm",
  "sourceTs": "2025-03-18T08:12:33.250Z",
  "serverTs": "2025-03-18T08:12:33.310Z",
  "quality": "Good",
  "channel": "PLC_Line1"
}

如果边缘网关与中心平台之间存在时钟偏差，建议在边缘侧启用NTP同步，并在中心平台按SourceTimestamp入库，而不是按接收时间入库。否则在事后追溯工况时，会出现“数据到了但时间对不上”的问题。

五、从采集到集成的落地检查要点

• 位号清单先行：在配置任何通道之前，先确定每个位号的源设备、协议、采集频率、死区、单位、量程和所属资产模型节点。
• 网络分区与安全：现场控制网与边缘采集网之间应部署工业防火墙或单向网关；OPC UA启用证书认证，MQTT启用TLS和客户端证书。
• 断线缓存与续传：边缘侧必须配置本地缓存，网络恢复后按时间顺序补传，避免数据空洞。
• 命名空间统一：中心平台的位号命名应与边缘Topic、资产模型节点保持一致，例如采用“厂区/产线/设备/测点”四级结构。
• 可观测性：对每个采集通道监控“最后更新时间、丢包率、缓存积压量、质量码分布”，这些指标比单纯的“通/断”更能反映数据健康度。

当现场层、边缘层和中心层的数据流被清晰定义后，后续的资产模型绑定、KPI计算和可视化组态才能建立在可信的数据底座之上。OPC UA负责把现场语义“说清楚”，MQTT负责把数据“送得到”，而AVEVA Edge与Data Hub则负责在两者之间完成可靠的转换、缓存与分发。