3. 工业告警与事件的数据模型设计

在ThingWorx中落地工业告警与事件管理，第一步不是画界面，而是把“告警是什么、事件怎么分类、严重等级如何定义、状态如何流转、来源设备与资产如何关联”这五件事固化成可复用的数据模型。模型一旦确定，后续的告警规则、通知策略、看板统计和根因分析都建立在其之上。本节围绕这五个建模对象展开，并给出可直接在ThingWorx中落地的Thing Template、Thing Shape与数据表结构。

一、告警定义：把“一条告警”拆成可枚举的字段

告警定义（Alarm Definition）描述的是“什么条件下产生哪一类告警”。在ThingWorx中，推荐用一个Thing Template承载告警定义，而不是把定义散落在各设备的脚本里。核心字段包括：告警编码（AlarmCode，全局唯一，如 PUMP_OVERTEMP_HIGH）、告警名称、触发条件表达式、关联的指标（Property）、阈值与迟滞（Hysteresis）、去抖时间（Debounce）、自动清除条件、以及默认严重等级。其中迟滞和去抖是工业场景中最容易被忽略却最关键的两个参数：迟滞防止阈值附近反复抖动产生告警风暴，去抖要求条件持续满足一段时间才真正触发。

例如一台冷却水泵，温度指标 Temperature 高于 85℃ 触发高温告警，迟滞设为 3℃，去抖设为 10 秒。这意味着温度必须连续 10 秒高于 85℃ 才触发；触发后只有当温度回落到 82℃ 以下才自动清除。这两个数字直接决定了告警的“灵敏度”和“噪声水平”，必须在定义阶段就写清楚，而不是等到现场再调。

二、事件分类与严重等级：让告警可被排序和路由

事件分类（Event Category）解决“这是什么类型的问题”，常见分类包括：设备故障、工艺越限、通信中断、安全联锁、维护提醒、系统异常。分类决定了通知对象和处理流程——通信中断通常给运维，工艺越限给工艺工程师，安全联锁则必须同时通知现场与安全负责人。

严重等级（Severity）解决“先处理谁”。工业场景建议采用五级：Critical（紧急）、Major（重要）、Minor（次要）、Warning（警告）、Info（提示）。等级不是装饰字段，它直接参与通知路由、看板排序和SLA计时。下表给出一个可直接使用的等级定义示例：

三、状态机：告警生命周期的唯一真相

告警状态机是数据模型中最需要严格定义的部分。推荐使用六状态模型：Active（激活）→ Acknowledged（已确认）→ InProgress（处理中）→ Resolved（已解决）→ Closed（已关闭），以及一个旁路状态 Suppressed（已抑制）。状态迁移必须由明确的事件驱动，而不是任意赋值。

关键迁移规则：告警触发时进入 Active；操作员点击确认进入 Acknowledged，此时告警仍在，但表示“已有人接手”；开始处理进入 InProgress；条件恢复或人工判定解决进入 Resolved；确认无误后 Closed。Suppressed 用于计划检修期间的屏蔽，屏蔽必须带过期时间，避免“永久屏蔽”成为隐患。每次状态迁移都应记录时间戳、操作人和备注，这些记录是后续MTTA（平均确认时间）和MTTR（平均修复时间）统计的数据来源。

四、来源设备与资产建模：告警必须挂到资产树上

一条告警如果只记录“哪个Thing报了警”，在几十台设备时还能应付，到了几百上千台就会失控。正确做法是建立资产层级：Site（厂区）→ Area（区域）→ Asset（资产）→ Equipment（设备）→ Thing（物模型）。告警实例通过 sourceAsset 和 sourceThing 两个字段同时关联到资产节点和物模型，这样既能按资产树聚合统计，又能追溯到具体数据源。

在ThingWorx中，资产层级可以用一个 AssetThingShape 实现，包含 parentAsset、assetPath、children 等属性；设备Thing通过 ImplementsShape 继承该Shape。告警实例则用一个独立的 AlarmThingShape，字段包括：alarmCode、severity、category、state、sourceThing、sourceAsset、triggerTime、ackTime、resolveTime、closeTime、ackBy、comment。这些字段直接对应状态机的迁移记录和统计需求。

五、在ThingWorx中落地：从模型到可运行

落地路径可以概括为四步。第一步，在Composer中创建 AlarmThingShape 和 AssetThingShape，定义属性与服务。第二步，为每类设备创建Thing Template（如 PumpThingTemplate），在模板中声明该设备可能产生的告警编码与默认等级。第三步，用 AlarmDefinition 数据表存储告警定义，通过 GetAlarmDefinition 服务在运行时读取阈值、迟滞和去抖参数，避免硬编码。第四步，用ThingWorx的订阅（Subscription）或事件（Event）机制监听属性变化，当条件满足时调用 CreateAlarm 服务生成告警实例，并触发状态机迁移服务。

下面是一段可直接参考的告警创建服务伪代码，展示了参数如何从定义表读取并写入告警实例：

// CreateAlarm 服务（ThingWorx JavaScript 服务示例）
var def = Things["AlarmDefinitionTable"].GetAlarmDefinition({
    alarmCode: "PUMP_OVERTEMP_HIGH"
});

var currentTemp = me.Temperature;
var isTriggered = currentTemp > def.threshold;

if (isTriggered && !me.alarmActive) {
    // 去抖：检查持续时间
    if (me.tempAboveThresholdSince == undefined) {
        me.tempAboveThresholdSince = new Date();
    }
    var elapsed = (new Date() - me.tempAboveThresholdSince) / 1000;
    if (elapsed >= def.debounceSeconds) {
        Things["AlarmManager"].CreateAlarm({
            alarmCode: def.alarmCode,
            severity: def.defaultSeverity,
            category: def.category,
            state: "Active",
            sourceThing: me.name,
            sourceAsset: me.assetPath,
            triggerTime: new Date()
        });
        me.alarmActive = true;
    }
} else if (!isTriggered && me.alarmActive) {
    // 迟滞判断：回落到 threshold - hysteresis 以下才清除
    if (currentTemp < (def.threshold - def.hysteresis)) {
        Things["AlarmManager"].ResolveAlarm({
            alarmCode: def.alarmCode,
            sourceThing: me.name,
            resolveTime: new Date()
        });
        me.alarmActive = false;
        me.tempAboveThresholdSince = undefined;
    }
}

完成上述建模后，一条告警从产生到关闭的全过程都有据可查：它来自哪个资产、属于哪类事件、严重等级如何、经过谁确认、何时解决。这套数据模型是后续告警规则引擎、通知策略和运维看板的共同基础，也是ThingWorx工业告警平台能否长期稳定运行的关键。