2. ThingWorx整体架构解析

ThingWorx 不是单一软件，而是一套围绕工业物联网应用全生命周期构建的平台组合。理解它的整体架构，关键不是记住产品名称，而是看清“数据从设备到应用、再到业务系统”这条链路上，每一层由谁负责、组件之间如何衔接。本节从分层架构入手，再逐一拆解核心组件，最后落到部署模式与许可模型这两个直接影响项目落地成本与运维方式的问题上。

一、平台分层架构：从设备到业务应用的四层结构

ThingWorx 的架构可以按职责划分为四层，自下而上依次是连接层、数据与建模层、应用构建层、集成与编排层。这个分层不是物理部署的强制约束，而是理解组件归属和职责边界的逻辑框架。

连接层负责把现场设备、PLC、网关、传感器接入平台。ThingWorx 本身不直接“驱动”所有工业协议，而是通过 ThingWorx Edge、Kepware（工业连接服务器）以及支持 MQTT、OPC UA、REST 等标准协议的接口完成数据采集。以一台支持 OPC UA 的数控机床为例，Kepware 作为 OPC UA Client 读取机床的转速、进给、报警等标签，再通过 ThingWorx Edge 或工业网关以 MQTT 方式把数据推送到平台。这一层解决的是“数据能不能进来、以什么频率进来、进来时带不带时间戳和质量码”。

数据与建模层是 ThingWorx 的核心特色所在。它不要求你先建一张宽表再写代码，而是用“Thing（事物）”这一抽象对象来映射物理实体。一个 Thing 可以代表一台设备、一条产线，甚至一个订单。Thing 由 Thing Template（事物模板）定义属性、服务、事件和订阅，Thing Shape 则用于把可复用的能力片段组合进模板。属性（Property）承载实时值，服务（Service）承载可被调用的业务逻辑，事件（Event）与订阅（Subscription）承载状态变化的响应。数据落到 Value Stream 或数据表中，历史数据可对接 PostgreSQL、InfluxDB 等外部存储。这一层解决的是“数据进来之后以什么结构被理解、被查询、被触发”。

应用构建层由 Mashup Builder 承担。它提供拖拽式的可视化开发环境，把按钮、图表、表格、地图、3D 模型等 Widget 组合成页面，并通过绑定把页面元素与 Thing 的属性、服务连接起来。Mashup 可以发布为 Web 页面，也可以嵌入移动端。这一层解决的是“人如何看到数据、如何操作设备”。

集成与编排层由 ThingWorx Flow 承担。Flow 用可视化编排的方式把 ThingWorx 内部服务与外部系统（ERP、MES、邮件、企业微信、数据库）串起来，支持定时触发、事件触发和手动触发。例如当设备报警事件触发时，Flow 可以自动在 MES 中创建工单，并向值班人员发送通知。这一层解决的是“平台内的数据如何驱动平台外的业务动作”。

二、核心组件：各自解决什么问题

ThingWorx Foundation 是平台底座，提供建模引擎、运行时、权限体系、数据存储接口和 REST API。所有 Thing、Mashup、Flow 最终都运行在 Foundation 之上。它决定了平台能承载多少并发连接、多少 Thing 实例、多少数据点。Foundation 的版本与许可直接决定后续组件的可用范围。

Mashup Builder 是面向应用开发者的可视化工具。它的关键能力不是“画页面”，而是“绑定”。一个典型的设备监控 Mashup 包含：一个显示设备列表的表格 Widget，绑定到设备 Thing 的查询服务；一个实时趋势图，绑定到某个温度属性的 Value Stream；一个报警列表，绑定到事件订阅。开发者不需要写前端框架代码，但需要理解 Widget 的输入输出与 Thing 服务之间的映射关系。

ThingWorx Flow 是集成编排工具。它把“当……就……”这类业务规则从代码中抽离出来，变成可维护的流程图。Flow 的触发方式包括：Thing 事件触发、定时触发、Webhook 触发。每个 Flow 由触发器、条件判断、动作节点组成。动作节点可以是调用 ThingWorx 服务、发送 HTTP 请求、写入数据库、发送邮件。Flow 的价值在于把平台内的实时数据与平台外的业务系统连接起来，而不需要为每个集成点单独开发。

此外，ThingWorx 还包含 ThingWorx Analytics（用于异常检测、预测性维护等分析场景）和 ThingWorx Kepware（工业连接）。它们不是每个项目都必须启用，但一旦涉及设备预测或复杂协议接入，就会成为关键组件。

三、部署模式：三种典型选择

ThingWorx 支持三种主流部署模式，选择哪一种取决于数据主权要求、运维能力和网络条件。

• ThingWorx 云（PTC 托管）：由 PTC 在云端托管 Foundation 及相关组件，用户通过浏览器访问。优点是开通快、免运维、自动升级；缺点是数据存放在云端，对网络稳定性有要求，且部分行业合规场景可能不接受。
• 私有云 / 客户自建：部署在客户自己的云环境或数据中心，可以是单机、集群或高可用架构。适合对数据主权要求高、已有云基础设施的企业。需要自行负责安装、升级、备份和容量规划。
• 边缘部署：在靠近设备的边缘节点部署 ThingWorx Edge 或轻量级运行时，先在本地完成数据采集、缓存和简单规则判断，再把汇总数据上传到中心平台。适合网络不稳定、数据量大或对实时性要求高的场景。

实际项目中，三种模式经常混合使用：边缘节点负责采集和本地告警，中心平台负责建模、应用和分析，云端或私有云承载 Mashup 与 Flow。部署模式的选择会直接影响许可的计费方式和运维分工。

四、许可模型：按什么计费，怎么选

ThingWorx 的许可模型主要围绕“连接规模”和“功能范围”两个维度展开。常见的许可类型包括：

需要特别注意的是，许可不是“买断即永久可用”。多数许可按年订阅，且不同版本（如 Foundation 的基础版与高级版）在 Thing 数量上限、API 调用频率、是否支持集群等方面存在差异。在项目初期做容量规划时，应先估算需要建模的 Thing 数量、需要接入的设备数、Mashup 的并发访问量，再反推需要的许可档位。如果低估了 Thing 数量，后期扩容可能面临重新采购和迁移成本。