📚 课程目录第4章缺陷数据采集与接入

4. 缺陷数据采集与接入

缺陷数据采集与接入是质量工单闭环的“入口工程”。如果入口数据不完整、时间戳不一致或图像与检测结果无法对应，后续的缺陷聚类、根因分析和工单派发都会建立在不可靠的基础上。本节围绕产线设备、MES、QMS 与图像存储四类对象，说明接口设计、协议选择与实时采集策略。

一、四类数据源的角色与数据边界

在一条典型的视觉检测产线上，四类系统承担不同职责：

产线设备（PLC/相机/工控机）：产生检测结果、触发信号、工位状态、节拍计数。数据特点是高频、短小、强实时，典型频率为每件 1～5 条记录，节拍 200～800 ms。
MES：提供产品序列号（SN）、工单号、批次、物料、工艺路线。它是缺陷记录的“身份来源”，用于把一条缺陷关联到具体产品与生产上下文。
QMS：接收缺陷记录、判定结果、处置状态，是质量工单的落库与流转系统。
图像存储：保存缺陷图像、原图、标注图，通常以对象存储或文件服务形式提供，返回可访问的 URL 或对象键。

接口设计的核心原则是：设备侧只负责“产生事实”，MES 负责“补充身份”，QMS 负责“形成工单”，图像存储负责“保留证据”。四者之间通过一个采集接入层解耦，避免设备直接写 QMS 造成耦合与阻塞。

二、接口设计：统一缺陷事件模型

四类数据源字段各异，接入层必须把它们归一为统一缺陷事件模型。一个可落地的字段集合如下（示例字段，实际按产线调整）：

{
  "event_id": "D20250612-000871",      // 全局唯一，用于幂等
  "sn": "SN-8A3F-2291",                // 来自 MES
  "work_order": "WO-20250612-07",      // 来自 MES
  "station": "AOI-03",                 // 来自设备
  "defect_type": "solder_bridge",      // 来自设备/算法
  "confidence": 0.93,                  // 算法置信度
  "capture_ts": "2025-06-12T14:23:07.412+08:00",
  "image_url": "https://img.example.com/aoi03/20250612/000871.jpg",
  "result": "NG",                      // 判定结果
  "source": "aoi_camera_03"
}

其中 event_id 是幂等键，sn 是关联键，capture_ts 必须统一为带时区的 ISO 8601 格式。时间戳对齐是常见坑：设备本地时钟、MES 服务器时钟、图像存储写入时间可能相差数百毫秒甚至数秒。建议在接入层统一以设备触发时刻为准，并记录 ingest_ts 作为入库时间，两者都保留，便于排查时序问题。

三、协议选择：按数据特征匹配

协议选择不是越新越好，而是匹配数据频率、实时性和可靠性要求：

数据源	推荐协议	理由	注意事项
PLC / 设备信号	OPC UA	工业标准，支持订阅与语义建模	需配置节点映射与采样周期
相机 / 工控机结果	MQTT	轻量、发布订阅、适合高频小消息	QoS 建议 1，避免重复与丢失
MES 查询	REST / HTTPS	请求-响应模式，按 SN 查询	加缓存，避免每件都查
图像存储	对象存储 SDK / HTTP	大文件上传下载，返回 URL	先传图再发事件，保证 URL 可用
接入层到 QMS	Kafka / HTTPS	异步解耦，削峰填谷	消费端幂等，按 event_id 去重

一个常见误区是让相机直接调用 QMS 的 REST 接口。产线节拍紧张时，QMS 的响应延迟会直接拖慢检测节拍。正确做法是相机或工控机只把结果发到 MQTT Broker，接入层异步消费并写入 QMS。

四、实时采集策略：缓冲、对齐与补传

实时采集的关键不是“快”，而是“不丢、不重、可追溯”。建议采用以下策略：

边采集边缓存：设备侧或接入层维护本地队列（如 SQLite 或内存队列），先落本地再发远端。断网时队列保留最近 30 分钟数据，恢复后按时间顺序补传。
SN 关联与时间窗对齐：设备结果到达时，用 SN 向 MES 查询工单信息。若 MES 暂时不可用，可先缓存事件，标记 mes_pending=true，后续补齐。
图像先传后发：图像上传成功后拿到 URL，再发送缺陷事件。避免 QMS 收到事件却取不到图。
幂等去重：QMS 侧以 event_id 为唯一键，重复写入直接忽略。重试采用指数退避，如 1s、2s、4s、8s，最多 5 次。
监控与告警：采集延迟（capture_ts 到 ingest_ts 的差值）超过 5 秒告警；队列积压超过 1000 条告警；图像上传失败率超过 1% 告警。

实操建议：接入层部署在产线边缘服务器上，与设备同网段，减少网络抖动。QMS 和图像存储可以部署在中心机房，通过专线或 VPN 连接。边缘层负责协议适配、缓存和初步清洗，中心层负责落库、分析和工单流转。

五、一个可参考的采集配置样例

以下为接入层 MQTT 订阅与 QMS 写入的配置片段（示例，非实测）：

mqtt:
  broker: "tcp://192.168.10.21:1883"
  topic: "aoi/+/result"
  qos: 1
  client_id: "defect-collector-01"

qms:
  endpoint: "https://qms.example.com/api/v1/defects"
  auth: "Bearer ${QMS_TOKEN}"
  retry: 5
  backoff: [1, 2, 4, 8, 16]   # 秒

buffer:
  type: "sqlite"
  path: "/data/defect_buffer.db"
  max_age_minutes: 30
  max_records: 5000

image:
  upload_first: true
  bucket: "defect-images"
  url_ttl_hours: 72

配置完成后，用一条模拟事件验证链路：向 aoi/03/result 发送一条 JSON，观察接入层日志是否出现“接收→清洗→查 MES→传图→写 QMS”的完整记录，并在 QMS 中确认该 event_id 已落库且 image_url 可访问。若 QMS 返回 409 冲突，说明幂等生效，属于正常现象。

注意：时间戳必须带时区。若设备只提供本地时间且无时区，接入层应统一按产线所在时区补全，并在事件中保留原始时间字段，避免跨时区工厂出现时序错乱。

完成本节接入设计后，缺陷数据从“设备产生”到“QMS 可查”形成了一条可监控、可补传、可去重的链路。这条链路的稳定性直接决定后续缺陷聚类与工单闭环的可用性，因此建议在产线试运行阶段就用真实节拍压测，观察队列积压与采集延迟两个核心指标。