4. 联动工程核心模型

设备异常与维修工单的联动，本质上不是“把报警推给维修”，而是让四类模型在同一套语义下协同工作：异常事件模型负责把设备侧发生的异常描述清楚，工单模型负责把维修任务描述清楚，关联关系模型负责把两者绑定并记录因果与追溯路径，联动规则引擎负责在什么条件下、以什么方式、把哪个事件变成哪张工单。四者缺一，联动就会退化为“消息转发”。

一、异常事件模型：把“发生了什么”结构化

异常事件模型的核心是让一条事件具备可判定、可去重、可升级、可追溯的能力。建议至少包含以下字段：事件标识（event_id）、设备标识（asset_id）、测点或部件（point_code）、事件类型（event_type，如超温、振动越限、通信中断、工艺参数漂移）、严重等级（severity：提示/警告/严重/紧急）、发生时间（occur_time）、恢复时间（recover_time）、持续时长（duration）、触发值（trigger_value）、阈值（threshold）、数据质量码（quality）、事件状态（state：活动/已恢复/已确认/已关闭）、来源系统（source，如SCADA、振动监测、点检APP）。

其中两个字段最容易被忽略却最关键：数据质量码和事件状态。质量码为“可疑/无效”时，事件不应直接触发紧急工单，而应先进入待确认队列；事件状态则决定联动引擎是否允许重复触发。例如同一测点5分钟内重复上报超温，应通过“设备+测点+事件类型”做去重窗口，避免一次真实故障生成十几张工单。

二、工单模型：把“要做什么”结构化

工单模型需要承载任务、资源、时间与结果四类信息。典型字段包括：工单号（wo_id）、工单类型（抢修/计划检修/点检复核/隐患整改）、关联事件（event_id，可空）、设备标识、故障现象描述、优先级（P1~P4）、要求响应时间、要求完工时间、指派班组/责任人、所需备件、安全措施、实际开始/结束时间、处理措施、更换备件、停机时长、验收结论、关闭状态。

工单类型与优先级的映射必须与事件严重等级解耦又关联：事件等级决定“建议优先级”，工单类型决定“流程路径”。例如“严重”事件默认生成P2抢修工单，但若该设备属于单点关键设备（无冗余），规则可将其提升为P1；若同类事件在24小时内已存在未关闭工单，则不再新建，而是追加到已有工单的关联事件列表。

三、关联关系模型：让事件与工单可追溯

关联关系模型解决“谁由谁触发、谁合并了谁、谁验证了谁”。建议采用显式关联表，而不是只在工单里存一个event_id。关联表字段可设计为：relation_id、source_type（event/workorder）、source_id、target_type、target_id、relation_type（触发/合并/根因/复检/衍生）、创建时间、创建方式（规则自动/人工）、置信度（可选）。

这样设计后，可以支持三类典型查询：正向追溯——某条超温事件最终产生了哪些工单、是否关闭；反向追溯——某张抢修工单是由哪些事件聚合而来；根因分析——同一设备一段时间内多个事件是否指向同一部件。关联关系模型是后续做故障树、重复故障统计和知识沉淀的数据基础。

四、联动规则引擎：把四类模型串起来

规则引擎的职责是“条件判断+动作执行”。条件侧读取异常事件模型字段与设备静态属性（关键等级、冗余情况、维保状态），动作侧操作工单模型与关联关系模型。规则建议采用“规则集+优先级+互斥”的结构，避免多条规则同时命中导致重复建单。

下面给出一组可直接参考的规则示例（参数为教学示例，实际需按现场标定）：

规则 R-01 超温抢修
WHEN event_type = "TEMP_HIGH"
 AND severity IN ("严重","紧急")
 AND quality = "有效"
 AND duration >= 60s
THEN 创建工单(type="抢修", priority=P2)
     建立关联(relation_type="触发")
     若 asset.critical = true 则 priority 提升为 P1

规则 R-02 重复事件合并
WHEN 已存在未关闭工单 且 同 asset_id + point_code
 AND 新事件 severity <= 已有工单关联事件最高等级
THEN 不新建工单
     追加关联(relation_type="合并")

规则 R-03 通信中断降级
WHEN event_type = "COMM_LOSS"
 AND duration >= 300s
THEN 创建工单(type="点检复核", priority=P3)
     备注"先确认现场仪表与链路，再判定设备本体"

规则执行顺序建议为：去重与合并 → 质量校验 → 等级提升 → 建单或追加 → 写关联 → 通知。通知动作应作为规则动作的一部分，而不是独立系统，否则容易出现“工单建了但没人收到”的断点。

五、落地时的三个关键判断

第一，事件与工单不是一对一。 一次设备故障可能产生多条事件（温度、振动、电流同时越限），规则引擎应支持“事件聚合建单”，把同一设备、同一时间窗内的事件合并到一张工单，并在关联表中保留每条事件的触发关系。否则维修人员会收到多张内容重复的工单。

第二，规则必须可解释。 每条自动建单都应在工单上记录“由哪条规则、基于哪条事件、在什么时间触发”。当现场质疑“为什么这张单是P1”时，能直接回溯到规则编号和事件字段，而不是靠人工回忆。

第三，模型要允许人工干预。 规则引擎自动建单后，允许调度人员调整优先级、合并工单、补充关联事件，但所有人工修改应写入关联关系表或审计字段。这样既保留自动化效率，又不丢失责任链。

把四类模型分开设计、通过规则引擎连接，最大的好处是变更可控：设备侧新增测点只改事件模型，维修流程调整只改工单模型，联动策略变化只改规则，而关联关系始终作为追溯底座保留。这样，异常与工单的联动才能从“能推消息”走向“可运营、可分析、可优化”。