定义
Rule Engine（规则引擎）根据设备 Telemetry、Connection Status 等条件触发告警、下发 Downstream Command 或调用 Webhook。支持阈值、表达式、组合条件，实现自动化运维。
规则组成
规则通常包含：数据源（设备属性、事件、连接状态等）、触发条件（阈值判断、表达式、多条件 AND/OR 组合）、冷却期（防止重复触发）、执行动作（告警、Webhook、下行指令、工单创建等）。支持按产品、分组、设备筛选规则生效范围，实现精细化策略。
典型场景
温度超限告警、设备离线超过 N 分钟告警、批量离线告警、设备健康度低于阈值触发维护工单、异常数据触发 Remote Diagnosis 远程诊断。规则可对接 ITSM、Webhook 实现告警闭环，或直接下发 Downstream Command 执行自动控制。
与 RUL 结合
规则引擎可与 RUL 剩余使用寿命预测结合，当设备预测寿命低于阈值时自动触发维护计划或工单。支持规则优先级、启用/禁用、版本管理，便于运维人员灵活配置与审计。
条件、冷却和动作是三条独立配置
一条规则至少分开三块：对什么数据做判断、多久内不再重复触发、触发之后做什么。判断只产生“条件成立”这个事实，冷却决定这个事实要不要再次对外，动作才是告警、开单、调用接口或下发指令。把三者写进同一段无法单测的脚本，修改阈值时会连带改掉通知对象。条件成立但不在冷却之外，应记成被抑制，而不是记成条件没发生，否则事后无法区分“没有越限”和“越限了但被压住”。
条件要用物模型里的标识和单位，不要用某个固件版本的原始寄存器地址。地址一改，规则仍在跑，比较的却是另一个量。组合条件要写明是同时成立还是任一成立，以及各个量的时间对齐方式。温度的最新值和一小时前的振动放在一起比较，会得到没有物理意义的结果。动作若会下发控制，必须引用服务名和参数模板，并限制在规则作者有权操作的设备上，不能因为规则由管理员创建，就让后来的编辑者借这条规则触达更多设备。
规则只应作用在筛选后的设备集合
使用条件是规则显式绑定产品、分组或标签。未绑定应视为不对任何设备生效，而不是对全部生效。不同产品即使属性同名，量纲也可能不同，共用一条阈值会误报。新设备入网后，只有它落入已写明的筛选条件才进入规则；靠“默认全选”会把试验设备也卷进生产告警。
动作的副作用要和筛选一起评审。自动下发重启前，应确认这批设备允许无人值守重启，并且同一台在冷却期内不会被另一条规则再次重启。开工单的规则要带合并键，例如同一设备、同一故障码在未关闭前不再开新单。规则发布前用历史物模型数据回放，看会命中多少台，再决定是否启用。没有回放就启用，第一条实时数据就可能打出大批动作。
冷却期设成零导致告警风暴
冷却为零时，每个采样点只要越限就触发一次。五秒上报的温度在阈值附近抖动，一小时会产生数百次告警和同等数量的外呼。接收方会关掉通道，真正的新故障随后也被淹没。冷却应覆盖正常抖动周期，并单独设置恢复条件：回到阈值以内持续一段时间才算恢复，恢复前的重复越限不再发新通知。
另一类风暴来自动作把规则自己又触发了。例如越限就写一个影子值，写入又产生属性变更，变更再次命中同一条规则。动作产生的事件应带来源标记，规则默认忽略自己刚刚写入的回声，或者把触发链的深度限制住。禁用规则不等于撤回已经发出的动作：已经在队列里的指令和已经打开的通知要单独处理。编辑规则时若直接改线上条件，半个窗口内会新旧条件交替，应先克隆、回放、再切换，保留上一版以便立刻退回。
规则上线后的第一天单独查看抑制计数、动作成功计数和动作失败计数。只有告警条数没有后两项时，无法知道是条件没成立，还是动作接口一直在失败。失败的动作要有自己的告警，不能只写在规则运行日志的末尾。规则之间的顺序若会影响同一台设备，写明哪一条先执行，以及后一条能不能看见前一条刚刚写入的值。看不见时应视为最终一致之前的正常现象，而不是把后一条的阈值调低去凑合。暂停规则要即时生效，已经排队但尚未发出的动作按暂停策略丢弃或放行，策略写在规则上而不是临时商量。同一条件被多条规则覆盖时，列出这些规则的动作，确认它们不会互相撤销。