模型案例


以下是几个成熟和错误的模型案例。

成熟案例

案例 1 - EnOS Edge

EnOS Edge 提供了智能边缘计算平台，通过整合继承传统 OT 技术，并与 EnOS Cloud 深度协同，提供强大的设备管理、设备控制、边缘计算、本地分析与决策等能力。


Edge 模型设计的是一个设备网关产品，网关产品设备也叫主设备，是指可以挂载子设备的直连设备，网关具有子设备管理模块，维持子设备的拓扑关系，并且可以将拓扑关系同步到云端。为应付大量数据的处理的场景，Edge 的功能定义设计只使用了模型的属性，测点，服务来完成功能定义，实现了能够将其它设备数据代理上传到 Iot Hub。


功能定义设计如下。

功能要素

功能定义

功能描述

属性

version, edge_type

版本和 Edge 类型。

测点

collect_status, debug_data, resource_ver,update_result, debug_datav2, pipeline_status, ping_point, common_status, work_status

运行的测点，主要涉及数据状态更新。

服务

debug_command, debug_switch, update_resource, arbitrament

调试和资源更新等服务。


从 Edge 的功能定义可以看出，对于网关产品模型的设计不需要关心其子设备的设计，使得 Edge 的模型简单清晰。

案例 2 - Solar Inverter

光伏逆变器是可以将光伏（PV）太阳能板产生的可变直流电压转换为市电频率交流电（AC）的逆变器，可以反馈回商用输电系统，或是供离网的电网使用。


由于市场上的光伏逆变器种类繁多，在不同项目可能会采用不同的品牌，EnOS Solar设计了标准的公有主逆变器模型，以便通过子模型继承主模型功能来扩展功能以实现特有品牌逆变器的接入和统一管理。其主模型的大致设计如下。


../../_images/solar_inv_model_features.png


从上图可以看出逆变器本身的设计比较复杂，主要涉及属性和测点两部分功能定义，通过领域专家指导，将众多逆变器的共同特性抽象到了主逆变器模型中。


以下是一些设计模型的技巧。

  • 测点命名：由于光伏的接入主要都是通过 Edge 直接采集 Scada 的数据，或者通过 API、SFTP 获取数据，可以看到在测点时为都加上了 “INV.” 的前缀，以方便在Edge 管理多类子设备情况下，配置模板时识别对应逆变器测点。

  • 公有模型的主模型和子模型使用：在使用模型时，EnOS Solar 的规范是所有设备只能通过子模型创建，不能直接基于公有主模型下。命名统一规范，公有子模型以 EnOS_Solar_XXX_Generic 命名，如果存在特定厂商模型则以 EnOS_Solar*INV*{厂商代码}_{型号} 命名。

    ../../_images/solar_model_schematic_diagram.png


  • 私有模型使用: 如果在使用过程中，用户需要再创建特殊的私有模型，由物联网交付实施团队中的模型管理人员在OU中自行创建及维护；必须从某个公有子模型中继承而来，并且遵守模型ID规范和测点命名规范；整体看来，光伏建议模型为三层结构，即: 公有主模型 > 公有子模型 > 私有子模型

错误案例

案例 1 - 未使用公有模型创建设备

以 EnOS Edge 为例，EnOS Edge 是一个标准的公有模型，在公有模型中可以查看其基本信息和功能定义, 模型名称为 EnOS_Edge_Standard_Model。

../../_images/edge_public_model1.png


../../_images/edge_public_model2.png


常见的错误使用方式有两种：

  1. 用户自己创建 Edge 私有模型

  2. 使用标准的 Edge 模型导出后进行导入创建了私有模型。


标准使用方式是直接使用 Edge 公有模型 EnOS_Edge_Standard_Model，在每个 OU 下创建名称为 EnOS_Edge_Standard_Product 网关产品的设备，而不需要自己创建私有模型，从而可以在 System 管理账户下统一升级管理 Edge 模型和在 DevPortal 中使用 Edge 管理功能对其进行模板、规格等功能的配置管理。

备注

  • 1、 为了区分是 EnOS 标准 Edge,产品名称要为 EnOS_Edge_Standard_Product。

  • 2、 产品类型必需选择为网关，否则在 Edge 管理中找不到设备。

案例 2 - 不同类型设备模型不进行抽象

在模型的设计阶段，需要将接入的设备资产共同特征进行抽象。一种错误的使用方式是将这些可以进行抽象分离的资产创建到了同一个模型上。


以需要建立表计模型为例，某项目在模型设计阶段，需要创建一个电表模型,模型名称为 Meter，为其创建了电表相应的测点 Ua、Ub、Uc，并创建了一个产品名为电表的产品和相应的设备。随着项目的迭代，后续有了水表的需求，发现已经有了 Meter 模型，并且还可以继续在上面添加水表测点，就重复利用 Meter 模型创建一个产品名为水表的产品和相应的设备。随着项目的推进，又要加入燃气表等，发现 Meter 模型越来越臃肿难以维护。


上面的问题主要是把电表，水表、燃气表本身是不同表计的测量表，建立在了同一个模型上，正确的做法是需要分别进行建模，分别创建 Electric meter、Water meter、Gas meter 的模型分别进行管理。

案例 3 - 创建过多类似的模型

在某些项目场景下，项目上更关注对设备数据的收集处理，从而可能忽略了对设备模型的抽象和建立，从而出现了分别创建一个模型，一个产品，一个设备来进行业务处理的情况，这种做法是错误的。


需要注意的是，在同一个 OU 下，创建私有模型的上限数据量为1000个。 如果上述情况不加以检查，会很容易达到1000个的限制。


因此，推荐的方法是识别和抽象相似设备的特征并将它们归为一个模型，防止创建太多功能相似的模型，防止私有模型创建滥用从而避免导致最后私有模型资源不足的情况。

案例 4 - 创建无意义的流计算测点

在设备数据开发阶段，因业务需求原因通常会向已经创建好的模型中添加流式计算所需要的测点。


常见的错误使用方式有两种：

  1. 模型设计完成后添加流计算输出所需要的测点。

  2. 在模型中添加流式计算的中间测点，而不保存数据值。

流式计算输出点是建模的一部分，建议在模型设计阶段就考虑好流计算输出测点的设计，而不是在数据开发阶段再设计，通常模型管理和数据开发是不同的阶段，涉及人员的权限也不相同，流式计算阶段应该更关心计算逻辑的完善而不是建模。另外，对于不需要输出的流式计算模型测点，只是中间测点，是不需要为其创建为模型测点的。