物联网物模型

1. 背景

万物互联，为数据创建价值；生活中，家用智能空调、智能扫地机器人、智能电视等等，物联网技术其实早早就已经走进了千家万户，当前疫情大背景下，远程办公、健康码、核酸检测电子报告等等，更使得听起来高大上的物联网从幕后走到台前，不过目前物联网领域，山头林立——短时间甚至可遇见的未来这一情况将一直延续，不同厂家之间、不同行业之间数据互不相通，加大的限制了物联网的发展：
一、数据价值低：物联网数据具有多源异构、规模巨大等特性，使得数据解析与数据共享困难。与此同时，海量数据之间缺少业务关联 性，导致数据利用效率低下，数据价值无法充分利用。
二、业务复制成本高：不同设备的标准各异，设备接入开发成本高、时间长。随着行业应用和设备量增长，新增应用需要针对不同的标 准多次定制开发，造成业务的复制成本增高。
三、产业链合作难：不同厂家之间的接入协议、数据模型数量众多且各自封闭，产业链内部自成体系，使得产业链各主体间协作困难，
设备联动及维护难度大，服务兼容性差，严重影响用户体验。

2. 物模型类别

物模型是将实体设备抽象化建模以后，对设备进行标准的数字化描述。形象来说，物模型为设备间互动提供了“普通话”，这样可以对设备产生的数据进行统一、标准的描述，实现海量数据的识别、解析与共享，深度挖掘数据价值随着物模型研究逐渐形成业界共识，众多行业标准组织、ICT厂商、运营商等单位都在物模型标准方面积极布局。目前，多家标准组织和行业联盟均在研究和跟进物模型相关标准，但尚缺乏主流的、被产业广泛实施的物模型标准。

2.1 ICA

ICA：由阿里巴巴发起，是一个研究物联网接入协议、设备管理等业务标准的行业联盟，是国内物模型研发的领军者。目前ICA已发布了自定义的物模型标准，包括设备抽象模型（如图4所示）及TSL（Things Specifification Language）描述语言，并研发了开发平台，为物模型 应用提供丰富的落地工具。

2.2 OneDataModel

OneDM的目标是建立一组描述物联网设备的通用数据和交互模型。这将使应用程序能够与来自不同生态系统的物联网设备一起工作，而无需将数据和交互从一个组织的模型转换为另一个组织的模型。

• sdfObject
  对象，一组中列出的项目sdfObject，是用于模型构建的可重用语义的主要“原子”。sdfObject包含一组sdfProperty、sdfAction和 sdfEvent定义，这些定义描述了与某些功能范围相关的交互可供性，对于定义的粒度，定义sdfObject的范围应保持足够窄，以实现广泛的重用和互操作性。sdfObject 例如，使用单独的开/关控制、调光和颜色控制可供性定义来定义一个灯泡，将能够为不同的产品类型配置可互操作的功能。可以使用通用开/关控制的sdfObject定义来控制可能需要开/关控制的不同种类的事物。

Quality在 SDF 中表示为 JSON 映射（对象）中的条目，用作定义或声明

• sdfProperty
  sdfProperty用于对sdfObject实例中的状态元素进行建模,sdfProperty实例可能与某些协议可供性相关联，以使应用程序能够获取状态变量，并且可选地修改状态变量。此外，一些协议提供状态变化的及时报告。（这三个方面由质量readable、 writable和observable定义sdfProperty。
  sdfData主要用于约束sdfProperty中所定义的数据的结构和值的质量，以及这些数据相关的语义的质量——语义的单位、单位缩放信息等

• sdfAction
  sdfAction组包含 Actions 的声明，模型可供性，当触发时，其效果不仅仅是读取、更新或观察事物状态，通常会产生一些外在的物理效果（其本身无法在 SDF 中建模）。从程序员的角度来看，它们可能被认为大致类似于方法调用。Action可能有入参，同时Action的执行可能存在异常、执行的结果也可能会失败，因此Action可能需要解决幂等性问题以及安全性问题
  sdfAction当前版本的SDF只为分组定义的输入输出数据提供数据约束建模和语义。同样，协议消息有效负载的数据定义，以及用于调用操作的详细协议设置，预计将成为协议绑定的一部分

• sdfEvent
  sdfEvent 包含了对具体事件的定义，其定义了物理设备事件信息的模型，可能作为数据保存到数据库，也可作为一个信号转发到相应服务
  请注意，与 sdfProperty 状态更改存在微不足道的重叠，也可以将其定义为事件，但通常不需要这样定义。但是，事件可能表现出某些排序、一致性和可靠性要求，这些要求有望在各种实现中得到支持，这些实现sdfEvent将 sdfEvent 与 sdfProperty 区分开来。例如，虽然状态更改可能会简单地被另一个状态更改所取代，但有些事件是“宝贵的”，即使有更多事件发生，也需要保留。
  SDF主要是对Event的数据做出约束，但是事件与报文中数据格式以及协议中事件调用的方式等，需要通过协议绑定来实现

• sdfData
  sdfData与sdfProperty分开定义， 数据约束和语义锚点概念，这些概念对于组成 sdfProperty 项的数据项分解，并用作 sdfAction 和 sdfEvent 项的输入和输出数据
  在 sdfProperty 项与 sdfAction 的输入或输出参数或 sdfEvent 提供的输出数据之间共享此类数据定义是一个常见用例。sdfData 定义还允许分解扩展的应用程序数据类型（如模式和计算机状态枚举），以便在具有相似基本特征和要求的多个定义中重用。

• sdfThing
  sdfThing 包含一个或多个sdfObject。sdfThing中的内容定义分为sdfObject 的定义和sdfThing 本身的元数据定义。

2.3 3IM（AII-DTML）

工业互联网产业联盟主导的工业互联网信息模型（3IM）所主导DTML 由一组核心元数据组成，用于定义所有物（Thing）的行为：
 属性 ( Property )
 命令 ( Command )
 事件 ( Event )
 数据模式 ( DataSchema )
 组件 ( Component )
 关系 ( Relationship )

2.4 电力模型规范

国家电网物联终端统一建模规范，通过模型标识符、模型描述、属性、消息和服务的描述，形成对电力物联终端设备数据信息的完整描述，支撑终端设备数据信息在电力物联网中的应用交互需求。

3.物模型思考

通过对比CIA、OneData、DTML、电网模型规范，发现大家对与设备的模型抽象的维度基本上都是一致的，大体上把“设备”抽象为属性、方法、事件，除此之外对于主要元素之间关系的抽象则不同的模型标准定义差别较大，当然，正如我文章开头所说，不同厂商、不同行业之间数据不互通的问题，通过物模型的标准化，可以解决同一物模型标准组织相关成员之间的数据打通问题，不过另一个问题却也很现实，不同模型组织之间的数据如何打通呢～～

————关于不同物模型之间数据打通的一些思考，目前在实际应用场景下，一般不同的行业会选择一个与当前行业想匹配的物模型规范，或者一些行业协会会主导当前行业物模型规范的定义和推广，因此大多数场景下我们应该考虑的是物模型与实际业务的关系；笔者将物模型在公司内部推广时，面临的设备类型种类繁多，行业领域跨度比较大，涵盖了能源、电力、工业、煤炭等多个行业，除了传统的数字量、状态量数据以外，还有大量的声纹、视频、音频、文件等类型的数据，因此物模型的落地主要需要考虑的问题，主要是如何将物模型和底层“百花齐放”的通信协议、多模态数据进行打通，因此笔者通过参考上文中多种类型的物模型规范，结合笔者协议开发经验，重新发布了适合实际需求的物模型规范，南向，增强了协议的扩展性，北向，提供统一、规范的设备数据查询、设备指令下发机制，同时对设备的类型进行了统一的定义，目前对公司在物联能力建设这块，取得了不错的效果。