企业官网建设流程全解析

值班员点了“确认”，设备温度却仍然高；温度恢复正常，待确认事件还在；通知服务显示成功，手机却没消息。这些不一定矛盾，因为发生、恢复、确认和投递是不同状态。

本文基于 Rapid SCADA v6 与本项目事件通知/视频联动实现说明。事件类型、限值、延迟和归档仍以实际配置为准；短信、消息渠道和视频属于另外配置的扩展。

1. 从一条时间线开始

假设演示高温阈值为 100，配置允许生成对应事件。数值与阈值只用于测试，不是设备整定值。

一次高温可以被确认但仍未恢复，也可以已恢复但尚未确认。界面应让人员看到这两种差异。事件确认不等于设备复位、清除保护或停止自动策略。

2. 原始数据、通道状态与事件各存一层含义

数值和质量先进入通道处理；事件按活动通道、事件配置和实际变化产生；事件归档保存可查询记录。不能把“设备画面变红”当成事件已经归档，也不能认为任何数值变化都会生成通知。

对离散状态，应写明 0、1 和其他码含义；对模拟量，应确认单位、倍率、阈值和是否使用延迟或滞回。驱动失联质量与工艺越限不同，应避免把无效值 0 当成工艺恢复。

排障时选一个事件身份，比较来源、通道、发生时间、状态和确认记录。聚合事件与单个测点事件也应保留关联关系，不能只按事件文字做去重。

3. 本项目通知轮询是快照，不是可靠消息队列

本次核对的 SweShell 事件通知从 Web 接口获取未确认事件快照，受当前用户权限、事件数量、时间深度与过滤条件影响；本地缓存事件身份，用于避免同一次会话重复弹出。

这意味着：

• 两次轮询之间发生又被确认的事件，可能不出现在下一次未确认快照中。
• 告警大量涌入时，数量/时间范围限制可能截断结果。
• 页面关闭、会话过期或网络中断时，不应假定前端持续消费。
• 刷新后的本地去重状态与服务端持久化投递记录不是同一种保证。

需要可靠通知时，应设计有持久化消费进度、重试与去重的服务端投递链，不能把前端弹窗轮询直接当作完整告警总线。完整历史追溯应查询事件归档，而不是仅查看当前弹窗。

本项目事件 ID 可能超过 JavaScript 安全整数范围，前后端应按约定保留字符串身份；转成浮点 Number 后再去重可能串事件。

4. 通知成功也有层次

建议以(事件身份, 渠道, 接收目标, 规则版本)等明确键标识一次投递，实际键设计应覆盖重试和规则变更需求。

接口超时可能发生在对方已经接受之后，简单重发会造成重复。接入渠道有幂等或查询能力时应使用；没有时如实描述交付语义，不能承诺“恰好一次”。

通知正文应能定位对象、测点、发生时间和事件身份，敏感信息按渠道范围处理。通知目标配置、服务账号与日志中的令牌不能出现在公开画面或文章截图。

5. 视频联动和统计分别依赖同一事件身份

本项目当前一条匹配的新事件可触发对应摄像机的实时预览，映射管理与对象权限另有检查。实时预览不能证明已按事件时刻定位录像。录像追溯还需网关录盘、回放接口和时间同步。

事件报表也需区分发生次数、未确认数量、确认耗时和故障持续时间。每次轮询看见同一事件一次就加一，会严重放大发生次数；用确认时间当恢复时间，则会把人员处理速度混进设备故障时长。

如果需要区间统计，先定义跨窗口事件如何裁剪，未恢复事件如何截止，以及无数据时如何标识未知。创建计算通道不自动提供历史窗口查询与时长统计能力。

6. 用五个用例验证完整链路

验收记录应能从一个事件身份追到通道原始变化、归档、确认和各渠道结果。链路中没有实现的持久化、回执或录像定位，应明确列出，而不是由一个绿色成功提示代替。

相关：告警视频联动与录像追溯、交付验收清单。

Rapid SCADA 中文网站：rapidscada.com.cn。