2. ThingWorx基础架构与核心概念
在ThingWorx中构建工业告警与事件管理平台，第一步不是画界面，而是理解它的建模语言。ThingWorx把物理设备、逻辑对象、数据结构和业务规则统一抽象成一组可组合的模型元素：Thing、ThingTemplate、ThingShape、属性、服务、订阅、数据表与流。只有先弄清这些元素各自的职责和它们之间的引用关系，才能把“设备温度超限要报警”这类需求准确地落到模型上。
从模板到实例：ThingTemplate、ThingShape 与 Thing
Thing是ThingWorx中最基本的运行时对象，代表一个具体的“东西”，例如一台编号为PUMP-101的离心泵、一个PLC连接、一个告警规则处理器。Thing本身通常不直接定义能力，它的能力来自所绑定的模板和形状。
ThingTemplate（事物模板）是创建Thing的蓝图，定义了一类对象共有的属性、服务、订阅和事件。例如可以建立“离心泵模板”，其中包含入口压力、出口压力、轴承温度、运行状态等属性，以及启动、停止、复位告警等服务。基于该模板实例化时，只需为每台泵填写具体属性值，就能批量获得一致的行为。
ThingShape（事物形状）是可复用的能力片段，用于横向组合功能。一个Thing可以同时实现多个ThingShape，例如“可告警对象”“可维护对象”“可远程控制对象”。ThingShape与ThingTemplate的区别在于：模板决定“这一类对象是什么”，形状决定“这个对象具备哪些可插拔能力”。在告警平台中，通常把告警状态字段、告警确认服务、告警清除订阅封装成“Alarmable”形状，任何需要告警的设备Thing都实现它，从而避免在每个模板里重复定义。
属性、服务与订阅：数据、动作与响应
属性（Property）是Thing上的数据字段，是告警判断的输入源。属性有名称、数据类型、默认值、是否持久化、是否记录到流等元数据。例如轴承温度属性可定义为NUMBER类型，单位℃，并开启持久化与流记录。属性值变化是驱动告警的核心信号。
服务（Service）是Thing上可被调用的逻辑单元，用JavaScript或Java编写，可以读取属性、写属性、调用其他服务、访问数据库。告警平台中常见的服务包括：评估告警条件、生成告警记录、确认告警、关闭告警、发送通知。服务既可以由用户界面按钮触发，也可以由订阅或定时器触发。
订阅（Subscription）是事件驱动的响应机制，它监听某个事件源，当事件发生时执行指定服务。订阅的典型结构是“事件源 + 事件类型 + 处理服务”。例如：当PUMP-101的轴承温度属性变化时，触发“评估温度告警”服务。订阅把“数据变化”和“业务动作”连接起来，是告警自动化的关键环节。
数据表与流：告警记录与实时数据
数据表（DataTable）是ThingWorx内置的关系型数据存储，用于保存结构化记录，例如告警历史表、设备台账表、告警规则配置表。数据表支持字段定义、索引、查询服务，适合保存需要长期保留、按条件检索的告警记录。
流（Stream）是面向时间序列的数据存储，用于高频写入的实时数据，例如每秒采集的温度、压力、振动值。流通常与属性绑定，属性值变化时自动写入流。流适合做趋势分析、阈值回溯和告警触发前的数据取证。
两者的分工可以这样理解：流回答“过去一段时间数据怎么变化”，数据表回答“发生过哪些告警、当前状态是什么”。在告警平台中，流用于判断和取证，数据表用于记录和展示。
映射到告警事件管理：一条完整的判断链
把上述元素组合起来，就形成告警平台的基本工作链。以PUMP-101轴承温度告警为例：
- ThingTemplate“离心泵模板”定义轴承温度属性，并实现ThingShape“Alarmable”，获得告警状态字段和确认服务。
- 基于模板创建Thing“PUMP-101”，属性轴承温度绑定到Stream，每次采集值写入流。
- 在PUMP-101上建立订阅：当轴承温度属性变化时，调用“评估温度告警”服务。
- 评估服务读取当前温度值，与阈值比较。假设高温阈值设为75℃，当前值78℃，条件成立。
- 服务生成告警记录，写入DataTable告警历史表，字段包括告警ID、设备名、告警类型、级别、触发值、触发时间、状态。
- 同时更新Thing上的告警状态属性，供界面绑定显示。
- 操作员在界面点击“确认”，调用Alarmable形状中的确认服务，更新数据表状态为“已确认”，并记录确认人和时间。
这条链中，属性是输入，订阅是触发器，服务是判断与执行逻辑，流是数据来源与取证依据，数据表是告警记录的最终归宿。四者缺一不可。
建模时的关键约定
在实际项目中，有几个容易出错的点值得注意。第一，属性变化订阅的触发频率取决于采集频率，如果每秒变化多次，评估服务会被频繁调用，需要在服务内做去抖或状态锁，避免同一告警重复生成。第二，告警状态字段建议放在ThingShape中统一定义，而不是每个模板各写一套，否则后续统计和界面绑定会非常混乱。第三，流适合保存原始值，数据表适合保存告警事件，不要把高频原始数据直接写入数据表，否则表会迅速膨胀。第四，服务的返回值要明确，评估服务应返回布尔值或告警对象，便于订阅链中的后续服务判断。
理解这些基础概念之后，后续的告警规则配置、事件订阅、状态流转和界面绑定，本质上都是在这套模型上做组合与扩展。ThingWorx的建模能力，正是通过模板、形状、属性、服务、订阅、数据表和流这几个元素的相互引用，把工业现场的复杂需求拆解成可管理、可复用、可追踪的模型单元。