1. 课程导入与ThingWorx平台定位
设备运维与预测维护并不是把传感器数据接上云就结束了。真正的工程目标，是让一台正在运行的设备在故障发生之前，被系统识别出"状态正在偏离正常"，并给出可执行的处置建议。这门课围绕 PTC ThingWorx 平台展开，讨论如何从设备接入、数据建模、状态监测，一路走到预测性维护的落地。在开始动手之前，需要先看清三件事：我们要达成的工程目标是什么，ThingWorx 在工业物联网技术栈中处于什么位置，以及这门课的学习路径如何组织。
一、设备运维的工程目标：从"坏了再修"到"提前干预"
工业设备的维护策略通常经历四个阶段。最早是事后维修：设备停机了才去修，代价是意外停机和二次损伤。随后是定期维护：按固定周期更换部件，虽然降低了突发故障，但会造成"还能用的零件被换掉"的浪费。再进一步是状态维护：依据振动、温度、电流等实时状态决定是否维修。最终目标是预测性维护：基于历史退化趋势和模型，预测剩余可用寿命，在故障窗口到来之前安排检修。
这四种策略的差别，可以用一个具体例子说明。假设某台关键水泵的轴承，其振动有效值（RMS）在健康状态下约为 1.8 mm/s，随着磨损逐步上升，当超过 4.5 mm/s 时进入报警区，超过 7.1 mm/s 则接近 ISO 10816 的停机阈值。事后维修只会在泵卡死时响应；定期维护可能每 3 个月换一次轴承，无论其实际磨损如何；状态维护会在 RMS 越过 4.5 mm/s 时报警；而预测性维护会进一步拟合 RMS 随运行小时数的上升斜率，例如观测到近 30 天 RMS 从 2.6 升到 3.9 mm/s，据此推算约 20 天后触及 4.5 mm/s，从而提前安排备件与停机窗口。
因此，本课程要建立的工程能力可以概括为一条闭环：采集可信数据 → 建立设备数字模型 → 计算并监测健康指标 → 识别异常与退化趋势 → 输出维护决策。ThingWorx 在这条闭环中承担的是"中枢"角色，而不是单纯的数据库或可视化工具。
二、ThingWorx 在工业物联网中的角色
一个典型的工业物联网系统自上而下可分为四层：设备层（PLC、传感器、变频器）、连接层（网关、边缘计算、协议转换）、平台层（数据接入、建模、分析、应用编排）、应用层（看板、工单、告警、移动端）。ThingWorx 位于平台层，向上支撑应用，向下对接连接层。
它的核心价值体现在几个关键能力上。其一是Thing 模型：把一台真实设备抽象为一个 Thing，用属性（Property）描述状态量，用服务（Service）封装可执行逻辑，用订阅（Subscription）定义事件响应。其二是ThingWorx Composer：以可视化方式完成建模、绑定与逻辑编排，降低开发门槛。其三是Mashup 与可视化：快速构建运维看板。其四是与 Kepware/工业协议网关的集成：通过 KEPServerEX 等把 Modbus、OPC UA、Siemens S7 等协议统一为可订阅的数据源。其五是分析扩展：可对接 ThingWorx Analytics 或外部模型服务，把预测结果回写为设备属性。
需要强调的是，ThingWorx 不是"数据湖"，也不是"SCADA 替代品"。它更接近一个面向设备的应用使能平台：把设备数据变成有语义的对象，再把这些对象组合成业务逻辑。理解这一点，才能理解后续为什么先建模、再绑定、最后编排。
三、整体技术栈与学习路径
从上面的分层可以看出，本课程的技术栈由四块拼成：工业协议与连接（Modbus TCP、OPC UA、S7 等）、ThingWorx 平台建模（Thing、ThingTemplate、ThingShape、Stream）、数据处理与健康指标计算（均值、RMS、峰峰值、趋势斜率、阈值与基线）、预测与决策（退化建模、剩余寿命估计、告警分级与工单联动）。
学习路径建议按"由下往上、由静到动"推进。第一阶段打基础：理解设备运维目标与平台定位，熟悉 Composer 界面与术语。第二阶段做接入：用 Kepware 或模拟器把一台设备的若干测点接入 ThingWorx，建立第一个 Thing 并绑定属性。第三阶段做建模：为设备定义属性、服务与订阅，建立数据存储与历史查询。第四阶段做监测：计算健康指标，配置阈值告警与事件。第五阶段做预测：引入趋势分析与模型，输出剩余寿命与维护建议。第六阶段做集成：把结果推送到看板、工单系统或移动端，形成闭环。
四、先建立三个关键认知
第一，模型先行。在 ThingWorx 中，先想清楚"这台设备有哪些属性、能提供哪些服务、什么条件下触发事件"，再去绑定数据源，比先接数据再补模型要高效得多。第二，数据质量决定预测上限。采样频率、时间戳对齐、量纲统一、缺失值处理，这些看似琐碎的环节，直接决定后续趋势分析是否可信。第三，预测的价值在于可执行。一个只显示"健康度 72%"的看板没有意义，能给出"建议 18 天内更换轴承，备件编号 XXX"的系统才有运维价值。