2. ThingWorx架构与核心组件

ThingWorx 并不是一个单一软件，而是一组围绕工业物联网应用全生命周期分工协作的组件集合。理解这套架构的关键，不是记住每个组件的名字，而是搞清楚三件事：每个组件负责哪一段工作、它的输入输出是什么、以及它与其他组件在什么位置交接。只有把边界划清楚，后续做设备接入、建模、可视化、流程编排时，才知道该打开哪个工具、把配置写在哪里。

一、五个核心组件的定位

ThingWorx Foundation 是整个平台的运行时底座与数据中枢。它提供模型存储、数据持久化、权限体系、REST API、事件与订阅机制，以及最关键的 Thing（事物）模型引擎。所有设备、资产、产线的数字化表示最终都落在 Foundation 里。它不直接面向操作者做界面，也不直接采集现场信号，而是"被调用、被写入、被查询"的那一层。可以把它理解为：模型和数据在这里活着。

ThingWorx Composer 是面向开发与建模人员的浏览器端工作台。它运行在 Foundation 之上，用来创建 Thing Shape（事物形态）、Thing Template（事物模板）、Thing（事物实例）、ThingWorx 服务（Service）、订阅（Subscription）、以及数据表、流等对象。设备运维中最常见的动作——为某型号电机建一个模板、为每台电机建实例、给实例挂上属性——都在 Composer 中完成。Composer 是"定义结构"的地方，它本身不产生运行时数据。

Mashup Builder 是可视化界面构建器，同样运行在浏览器中。它把 Composer 里定义好的 Thing、属性、服务绑定到界面控件上，形成监控看板、设备详情页、报警面板。Mashup 的输入是 Foundation 中的实时数据与查询结果，输出是给运维人员看的页面。它解决的是"人怎么看数据"的问题，不负责数据采集，也不负责业务规则判断。

ThingWorx Edge 是部署在现场侧的边缘组件，包括 Edge SDK、Edge MicroServer（EMS）、工业连接组件（如 Kepware 的 Industrial Gateway）等形态。它负责把 PLC、传感器、网关、OPC UA 服务器、Modbus 设备的数据采集上来，做必要的本地预处理，再通过 WebSocket 或 REST 安全地推送到 Foundation。Edge 解决的是"数据怎么从现场进来"的问题，是数据链路的起点。

ThingWorx Flow 是流程编排与集成组件。它以可视化方式把多个系统、多个服务串成一条自动化流程，例如"当设备温度超阈值 → 查询工单系统 → 创建维修工单 → 发送企业微信通知"。Flow 的输入通常是 Foundation 中的事件或外部系统的触发，输出是对外部系统（ERP、MES、邮件、消息平台）的调用。它解决的是"跨系统动作怎么自动执行"的问题。

二、协作关系：一条数据从现场到决策的路径

把五个组件放在一条链路上看，协作关系就清晰了。现场设备信号由 Edge 采集并上报，写入 Foundation 中对应 Thing 的属性；Composer 事先定义了这些 Thing 的结构、属性类型和订阅逻辑；当属性值变化触发订阅时，Foundation 执行服务逻辑，必要时调用 Flow 发起跨系统流程；而运维人员通过 Mashup Builder 构建的页面查看实时状态与历史趋势。这条链路可以用下面的图来理解。

三、边界划分的实践意义

明确边界能避免三类常见错误。第一类是把建模工作放到 Mashup 里做。Mashup 只能绑定已存在的 Thing 和服务，如果属性没在 Composer 中定义，界面上就绑不出来。正确顺序永远是先在 Composer 建模型，再到 Mashup 做界面。

第二类是把业务规则写进 Edge。Edge 适合做协议转换、数据过滤、断网缓存这类靠近现场的处理，但不适合承载复杂的跨设备逻辑判断。例如"三台空压机同时超温才触发停机"这种规则，应放在 Foundation 的订阅或服务中，因为 Edge 通常只看到自己那一路数据。

第三类是把 Flow 当成数据存储用。Flow 是无状态的编排层，每次执行完就结束，不保存设备历史数据。需要留存的数据必须写入 Foundation 的流（Stream）或数据表（Data Table），Flow 只负责在数据变化时触发外部动作。

四、一个设备运维场景的组件分工示例

假设要为一条产线上的 12 台振动电机做状态监控与预警，各组件分工如下。