2. 设备事件与连续信号的本质

在设备建模中，我们面对的数据并非同质。一类是“发生了什么”的离散记录，例如门磁被打开、急停按钮被按下、PLC 输出点由 0 变 1；另一类是“持续是多少”的连续量，例如电机温度、管道压力、电池 SOC。前者由事件驱动，后者由时间驱动。理解这两种机制的本质差异，是后续统一建模的起点。

事件驱动：状态跃迁的离散刻画

事件驱动的核心是“变化即数据”。系统只在状态发生跃迁的瞬间产生一条记录，记录通常包含时间戳、设备标识、事件类型和跃迁后的值。以一台智能电表为例，其“跳闸事件”可表示为：

{
  "device_id": "METER-07",
  "event": "TRIP",
  "ts": "2024-06-01T08:15:23.412Z",
  "from": "CLOSED",
  "to": "OPEN",
  "reason": "over_current"
}

这条记录不关心跳闸后电流如何衰减，只关心“闭合→断开”这一跃迁。事件驱动的优点是存储紧凑、语义明确、便于触发告警与联动；缺点是两次事件之间的状态需要靠“保持”推断，若事件丢失，状态机就会失真。

时间驱动：连续量的周期采样

时间驱动的核心是“按节拍取值”。无论信号是否变化，系统都按固定周期采样并写入时序库。例如对电机绕组温度每 5 秒采样一次：

ts                     value(℃)
2024-06-01 08:15:20    63.2
2024-06-01 08:15:25    63.5
2024-06-01 08:15:30    63.9
2024-06-01 08:15:35    64.4

时间驱动的优点是趋势完整、可做积分与统计、便于回放；缺点是数据量大，且采样周期决定了能捕捉到的最快变化——若温度在 2 秒内骤升，5 秒周期可能漏掉峰值。

两者的本质差异

事件驱动是“稀疏、非等间隔、以跃迁为中心”，时间驱动是“稠密、等间隔、以时刻为中心”。前者回答“何时变了”，后者回答“某时刻是多少”。在统一建模中，二者不能简单互相替代：把事件当连续量插值会伪造中间状态，把连续量当事件会淹没真正的跃迁。

为什么必须统一建模

若两类数据各自为政，会带来三个具体问题。第一，状态不一致：事件说“门已开”，但连续量中的门磁电压采样仍显示高电平，运维人员无法判断以谁为准。第二，查询割裂：要回答“昨天 14:00 电机是否过温且处于运行态”，需要同时查事件表和时序表，再手工对齐时间戳。第三，联动困难：告警规则若只订阅事件，会漏掉缓慢爬升的温度；若只订阅连续量，又无法感知瞬时跳闸。

统一建模的做法是：为每台设备定义一个状态对象，其中离散字段由事件更新，连续字段由采样更新，二者共享同一设备标识与统一时间基准。这样，一次查询即可同时获得“当前门状态”和“当前温度”，规则引擎也能在同一对象上做复合判断。

典型设备场景分析

以“智能机柜”为例，它同时包含两类信号。事件类：柜门开/关、风扇故障告警、UPS 切换。连续类：柜内温度、湿度、输入电压。若只建事件模型，温度爬升到 45℃ 的过程不可见；若只建连续模型，柜门被瞬间打开的语义会被淹没在采样点中。

合理的统一模型可设计为：

device: CABINET-03
  discrete:
    door: CLOSED        # 由门磁事件更新
    fan:  NORMAL        # 由风扇告警事件更新
    ups:  ONLINE        # 由 UPS 事件更新
  continuous:
    temp_c: 38.6        # 每 10s 采样
    humidity: 47.2      # 每 10s 采样
    vin_v: 220.4        # 每 1s 采样
  timebase: UTC, ms

基于该模型，一条复合规则可以写成：当 door == OPEN 且 temp_c > 42 持续 60 秒，触发“开门高温”告警。这条规则同时依赖离散字段和连续字段，正是统一建模的价值所在。

需要强调的是，统一建模不是把两类数据塞进同一张表，而是建立“设备状态对象”这一抽象：事件负责改变离散字段，采样负责刷新连续字段，时间基准保证二者可对齐。这样，后续的告警、回放、统计和联动才能在同一语义层上展开。