📚 课程目录第2章报警数据源与设备模型

2. 报警数据源与设备模型

报警分级与责任路由能否落地，第一步不在“分级规则”，而在“数据源是否可信、对象模型是否对齐”。如果报警信号来自不同系统却各自使用不同的设备命名，那么后续无论怎样配置分级阈值和责任路由，都会出现“同一台设备被识别成三个对象”“报警找不到责任人”的问题。本节围绕两个核心任务展开：一是从PLC、SCADA、IoT网关三类典型数据源采集报警信号，理解它们各自的数据形态与接入方式；二是建立“设备—产线—区域—责任人”的对象模型，让每一条报警都能沿着确定的路径找到归属。

一、三类报警数据源的信号形态与采集方式

PLC是报警信号最原始的来源。典型报警在PLC中表现为布尔量（如 M100.0 为 TRUE 表示“电机过载”），或整型故障码（如 DB10.DBW20 = 5 表示“变频器通信故障”）。采集PLC报警通常有两种方式：一是通过OPC UA/Modbus TCP等协议周期性轮询，二是通过PLC主动上报。轮询方式实现简单，但存在采集周期与报警持续时间不匹配的风险——若报警只持续200ms而轮询周期为1s，就会漏报。因此对短脉冲报警，应优先使用PLC的上升沿锁存或事件上报机制。

SCADA系统通常已经对PLC信号做了聚合与初步处理，报警以“报警记录”形式存在，包含时间戳、报警文本、优先级、确认状态等字段。从SCADA采集报警，优势是字段规范、可直接复用其报警文本；风险是SCADA的报警优先级可能与我们的分级标准不一致，需要做映射而非直接照搬。常见做法是通过SCADA的OPC DA/UA接口或数据库视图读取报警表，按 AlarmID 增量拉取。

IoT网关面向的是分散、异构、可能跨厂区的设备。它把Modbus、CAN、LoRa、MQTT等不同协议统一转换为MQTT消息，报警通常以JSON载荷发布到主题，例如 factory/line1/device7/alarm。IoT网关采集的关键在于“主题设计”与“载荷字段约定”：主题中应包含区域、产线、设备标识，载荷中应包含报警码、级别、发生时间、恢复时间。若主题设计随意，后续对象模型就无法自动关联。

二、对象模型：设备—产线—区域—责任人

对象模型的作用是给每条报警提供一条确定的“归属路径”。推荐采用四层结构：设备（Device）→产线（Line）→区域（Area）→责任人（Owner）。每一层都有唯一标识和必要属性，层与层之间通过外键关联。

设备层是模型的最小单元，字段至少包括：deviceId（全局唯一，建议用“区域码-产线码-设备序号”拼接，如 A1-L2-M07）、deviceName、deviceType、lineId、alarmSource（PLC/SCADA/IoT）。产线层字段包括 lineId、lineName、areaId。区域层字段包括 areaId、areaName、shiftOwner。责任人层字段包括 ownerId、ownerName、role（操作工/维修/工程师）、contact、backupOwnerId。

关键设计原则有三条。第一，设备标识必须全局唯一且可读，避免用PLC地址直接当设备ID，因为同一台设备可能同时有PLC报警和IoT网关报警。第二，责任人绑定在“区域+角色”而非“设备”上，否则设备增减时维护量巨大；具体设备可由区域责任人在值班时认领。第三，报警源与设备是多对一关系，一个设备可以有多个报警源，但最终都归到同一个 deviceId。

三、从采集到归属的完整示例

假设某工厂A1区域L2产线的M07电机，PLC中 M100.0 为过载报警，IoT网关主题为 factory/A1/L2/M07/alarm。采集侧配置如下：

# PLC采集点配置（示例）
point:
  id: "A1-L2-M07-PLC-OL"
  deviceId: "A1-L2-M07"
  source: "PLC"
  address: "M100.0"
  alarmCode: "OL-001"
  level: "critical"
  latch: true          # 短脉冲锁存

# IoT网关MQTT主题约定（示例）
topic: factory/{areaId}/{lineId}/{deviceId}/alarm
payload:
  alarmCode: "TEMP-H"
  level: "warning"
  ts: "2025-01-15T08:23:11Z"
  status: "active"

当报警到达后，系统按 deviceId = A1-L2-M07 查询对象模型，得到 lineId = L2、areaId = A1，再查区域责任人表得到当前班次责任人 ownerId = U1023（维修班组），备用责任人为 U1088。若报警级别为 critical，则同时通知责任人和备用责任人；若为 warning，仅通知责任人。这样，一条报警从采集到路由的路径就完整闭合了。

对象模型建议在系统上线前先做一次“设备台账对齐”：把PLC点表、SCADA报警表、IoT网关主题中的设备标识统一映射到 deviceId。这一步做扎实，后续分级和路由的配置量会大幅下降。

常见错误：直接用SCADA的报警文本作为设备标识。SCADA文本可能随工艺修改而变化，一旦文本变了，对象模型就断了。正确做法是用稳定的 deviceId 关联，报警文本只作为展示字段。

四、采集与建模的检查要点

采集完整性：PLC短脉冲报警是否启用锁存或事件上报，避免轮询漏报。
时间一致性：PLC、SCADA、IoT网关的时间戳是否统一到同一时区，否则报警排序和恢复判断会出错。
标识唯一性：deviceId 是否全局唯一，是否存在同一设备多个ID的情况。
责任人有效性：每个区域是否至少配置一名责任人和一名备用责任人，避免报警无人接收。
映射可维护：设备增减时，是否只需修改对象模型表，而不需要改采集配置和分级规则。

把数据源采集和对象模型这两步做稳，报警分级才有可靠的输入，责任路由才有明确的终点。后续的分级规则、通知策略和升级机制，都建立在这一节所描述的信号形态与对象关系之上。