4. 生产设备数据建模

在ThingWorx中，生产设备监控平台能否长期稳定运行，很大程度上取决于建模阶段是否把“设备类型”和“具体设备”分清楚了。ThingTemplate负责描述一类设备的共性能力，Thing实例则代表车间里真实存在的一台设备。以CNC加工中心和注塑机为例，如果直接把每台设备的属性、服务和事件都写在Thing实例上，后续新增设备、批量修改逻辑、统一升级模型时会非常被动。正确的做法是：先抽象出设备类型的ThingTemplate，再基于模板创建Thing实例，最后把实例与真实设备的数据源、接口和业务逻辑绑定起来。

一、ThingTemplate与Thing实例的职责边界

ThingTemplate可以理解为设备类型的“能力契约”。它定义这类设备必须具备哪些属性、可以执行哪些服务、会上报哪些事件。Thing实例则是该模板的一次具体落地，它继承模板中的属性、服务和事件定义，同时拥有自己的名称、数据源、当前值和运行状态。例如，CNC设备模板中定义主轴转速、进给倍率、刀具号、运行模式、报警代码等属性；某台编号为CNC-01的实例则保存这台机床当前的真实值。模板回答“这类设备应该长什么样”，实例回答“这台设备现在是什么状态”。

建模时建议遵循三条原则：第一，模板只放同类设备的共性内容，不放入某台设备独有的参数；第二，实例只做差异化配置和实时数据绑定，不重复定义模板已有的结构；第三，属性、服务、事件的命名要统一，便于后续在Mashup、告警和报表中复用。对于CNC和注塑机，虽然都属于生产设备，但它们的工艺参数差异很大，因此应分别建立CNC设备模板和注塑机设备模板，而不是强行合并成一个“生产设备模板”。

二、属性定义：从工艺参数到可采集数据点

属性是设备模型中最基础的部分，它决定了平台能“看到”设备的哪些状态。定义属性时，不能只把设备说明书上的参数照搬进来，而要考虑三个问题：这个属性是否会被采集、是否会被展示、是否会参与告警或分析。以CNC为例，主轴转速、进给倍率、刀具号、运行模式、报警代码、累计加工数都是典型属性。其中主轴转速和进给倍率是连续变化的模拟量，适合用Number类型；运行模式是枚举量，适合用String或自定义枚举；报警代码是整型，适合用Integer。注塑机则更关注料筒温度、注射压力、锁模力、保压时间、周期时间和当前模具号，这些属性直接决定产品质量和生产节拍。

在ThingWorx中定义属性时，需要为每个属性设置名称、数据类型、默认值、是否持久化、是否记录历史等选项。对于需要趋势分析的属性，例如主轴转速、料筒温度、注射压力，应开启历史记录，并设置合理的采集频率和存储策略。对于只在状态变化时才有意义的属性，例如运行模式、报警代码，可以只记录变化事件，避免产生大量重复数据。属性命名建议采用“设备类型_参数名”或统一的英文驼峰命名，例如spindleSpeed、barrelTemperature，这样在后续Mashup绑定和告警规则中更容易识别。

三、服务定义：把控制动作封装成可调用接口

服务代表设备可以执行的动作或平台可以发起的操作。在ThingWorx中，服务可以是脚本服务、REST服务、数据库服务或设备连接服务。对于CNC设备，典型服务包括StartCycle()、StopCycle()、ResetAlarm()、LoadProgram()；对于注塑机，典型服务包括StartMold()、StopMold()、SwitchMold()、AdjustTemperature()。这些服务不应直接写死在每个Thing实例上，而应定义在ThingTemplate中，实例继承后再绑定具体的设备连接或PLC地址。

以CNC的StartCycle()为例，模板中定义服务名称、输入参数和返回结构，实例中把服务实现绑定到具体的OPC UA节点或Modbus寄存器。当Mashup上的“启动”按钮被点击时，平台调用该实例的服务，服务再通过设备连接向PLC写入启动位。这样，同一套Mashup可以复用于所有CNC实例，不需要为每台设备单独开发页面。服务定义时还要考虑异常处理，例如设备离线、写入失败、权限不足等情况，应在服务脚本中返回明确的状态码和错误信息，便于上层界面提示操作人员。

四、事件定义：让设备主动“说话”

事件用于表达设备在运行过程中发生的、需要被记录或响应的状态变化。与属性轮询不同，事件通常由设备主动上报或由平台规则触发。CNC设备常见的事件包括刀具磨损预警、主轴过热、程序结束、报警触发；注塑机常见的事件包括料筒温度偏差、锁模力异常、模具更换完成、周期时间超限。在ThingTemplate中定义事件时，需要明确事件名称、事件参数和严重级别。例如ToolWearWarning可以携带刀具号、当前磨损量和阈值；BarrelTempDeviation可以携带实际温度、设定温度和偏差值。

事件定义完成后，可以在ThingWorx中通过订阅机制把事件推送到告警服务、邮件通知或Mashup实时刷新。对于生产设备监控平台，建议把事件分为三个级别：提示级、警告级和故障级。提示级事件只记录不打断生产；警告级事件需要在看板上高亮并通知班组长；故障级事件应触发停机逻辑并推送维修工单。这样，事件模型就不只是数据记录，而是真正参与生产管理。

五、从模板到实例的落地检查

完成ThingTemplate和Thing实例创建后，建议做一次建模检查，确认模板与实例之间的继承关系是否正确、属性是否都已绑定数据源、服务是否都能正常调用、事件是否都能被订阅和展示。以下检查表可作为建模完成后的快速核对依据。

总的来说，生产设备数据建模的核心是“先分类、再抽象、后实例化”。ThingTemplate定义设备类型的属性、服务和事件，Thing实例承载具体设备的实时数据和连接配置。属性解决“看什么”，服务解决“控什么”，事件解决“报什么”。三者配合，才能让CNC、注塑机等生产设备在ThingWorx平台中形成可复用、可扩展、可维护的数字模型，为后续的实时监控、告警管理和数据分析打下基础。