ThingWorx 入门 > IoT 编程 > 建模:为什么存在事物形态和事物模板?
建模:为什么存在事物形态和事物模板?
由于 ThingWorx 模型具有面向对象的性质,所以您可以定义允许重复使用的“组件”,然后使用这些组件来定义模型中的事物。对可重复使用组件的更改会自动反映在由这些组件定义的事物中。其目的是仅在一个位置定义行为,并使所有继承对象的行为均符合当前的父对象定义。这样一来,当需要更新时,您就无需对多种事物进行相同的更改。
事物形态和事物模板的实现使得继承模型易于维护。事物形态是基本定义组件。当事物或事物模板共享事物形态的定义时,我们就说事物或事物模板“实现了”事物形态。通常,事物形态应表现出特有的行为,这意味着它们会执行一组特有的服务和功能。事物模板可实现多个事物形态。建议使用事物模板来定义事物。
我们来看一个简单的示例。一个站点具有多种不同类型的设备。每台设备都会对站点执行一种截然不同的功能。为简单起见,我们假设有三种类型的设备:
变压器
混频器
空气处理器
该站点可能有五台变压器、二十台空气处理器和十二台混频器。这三种设备中的每一种均有很大差异。但也可能存在一些共性。假设每一件设备都由公司的 ERP 系统进行跟踪,因此具有公共数据 (事物属性)。我们还假设空气处理器和变压器需要根据特定指标更新用于基于状态的维护 (CBM) 的维护管理系统。
在分析此物理模型并决定如何将其转换为 ThingWorx 模型时,需考虑三种不同的行为分组:
1. ERP 资产行为
2. 基于状态的维护行为
3. 设备类型特定行为
在本示例中,您至少要定义两种事物形态来利用 ThingWorx 模型的工作方式。它们是:
1. ERP_Asset 事物状态 - 因为站点中的每台设备均有这个共同点。这样一来,对 ERP_Asset 事物形态进行的任何更改均会自动反映在站点的每一台设备上。
2. CBM_Asset - 因为不止一种资产类型需要此功能,所以将其定义为一种事物形态后,可通过实现事物来继承任何更改。如果将来混频器的维护转至 CBM 模型,则您可让混频器通过混频器事物模板 (如下所述) 来实现此事物形态,而不必更新所有混频器。
现在,您可以创建三个事物模板,分别用于每种设备类型。事物模板使得具有特定含义的事物更加易于创建和维护。在本示例中,您可使用三种设备类型事物模板来创建一个代表特定资产的事物,只需使用事物模板并为该事物指定一个唯一名称即可实现。
变压器事物模板
变压器事物模板将通过实现 ERP_Asset 和 CMB_Asset 事物形态来定义。变压器的所有特定属性、服务、事件和订阅也应该在变压器事物模板中定义。然后,对于每台变压器,使用变压器事物模板和唯一名称来定义 ThingWorx 模型中的变压器。
或者,您也可以定义一个变压器事物形态。在这种情况下,您的变压器事物模板将实现三种事物形态,即 ERP_Asset、CMB_Asset 和 Transformer 事物形态。此方法效果很好,但如果其他事物模板无法实现 Transformer 事物形态,则可不必使用此方法。
混频器事物模板
混频器事物模板将通过实施 ERP_Asset 事物形态来定义。混频器不使用 CBM 维护模型,因此不需要相关事物形态。混频器的所有特定属性、服务、事件和订阅也应该在混频器事物模板中定义。然后,对于每个混频器,使用混频器事物模板和唯一名称来定义 ThingWorx 模型中的混频器。
空气处理器事物模板
空气处理器事物模板与变压器事物模板类似。它应实现 ERP_Asset 和 CMB_Asset 事物形态。空气处理器的所有特定属性、服务、事件和订阅也应该在空气处理器事物模板中定义。然后,对于每个空气处理器,使用空气处理器事物模板和唯一名称来定义 ThingWorx 模型中的空气处理器。
现在,所有资产均已定义,您拥有了一个维护性能极好的模型。如果需要对 ERP_Asset 进行任何更改,则可在单一位置完成并进行测试。部署完毕后,站点上的每台设备都将自动继承新的功能。
这对您有帮助吗?