物模型你真的清楚吗？

物模型你真的清楚吗？

从一些文章以及物联网平台中，我们经常会听到“物模型”这个名词，但往往对其概念理解不够深入，不清楚它在实际应用中的体现，更不知道如何设计物模型。为了更好地理解物模型，本文将通过几个问题来详细讲解这一概念。

背景

万物互联，为数据创建价值；不过目前物联网领域，山头林立——短时间甚至可遇见的未来这一情况将一直延续，不同厂家之间、不同行业之间数据互不相通，加大的限制了物联网的发展：
一、数据价值低：物联网数据具有多源异构、规模巨大等特性，使得数据解析与数据共享困难。与此同时，海量数据之间缺少业务关联 性，导致数据利用效率低下，数据价值无法充分利用。
二、业务复制成本高：不同设备的标准各异，设备接入开发成本高、时间长。随着行业应用和设备量增长，新增应用需要针对不同的标 准多次定制开发，造成业务的复制成本增高。
三、产业链合作难：不同厂家之间的接入协议、数据模型数量众多且各自封闭，产业链内部自成体系，使得产业链各主体间协作困难，
设备联动及维护难度大，服务兼容性差，严重影响用户体验。

什么是物模型

物模型是物理世界的实体东西的一个抽象，是进行数字化描述后，用于数字世界的数字模型。这么说可能有点绕，更直接一点说就是，物模型是使用计算机可以理解的语言，说清楚这个产品是什么、能做什么事情，以及可以提供哪些信息。而抽象就是要提取出产品的共同特征，形成模型。以智能灯为例，不同的灯，尽管规格不同，但它们的属性是相似，比如都有开关状态的属性，功能逻辑也相仿。我们可以将这些特征标准化，形成智能灯的物模型。反过来，物模型也规约了设备的功能。新增加的设备，如果是同一类型的，在设计、研发中，会遵循相同的功能定义，有相同的特征，实现相同的服务。比如，灯都应该有“开”和“关”两种状态。物模型TSL（Thing Specification Language）是一个JSON格式的文件，它是物理空间中的实体，如传感器、车载装置、楼宇、工厂等在云端的数字化表示，从属性、服务和事件三个维度，分别描述了该实体是什么、能做什么、可以对外提供哪些信息。定义了物模型的这三个维度，即完成了产品功能的定义。

通过上述定义可以看到，物模型主要描述的是如何与设备通信的交互模型，即：如何读写设备的状态，如何给设备发命令，以及设备如何上报一个事件，例如产生的一条设备告警。更确切的说，是与设备上运行的app进行通信，但是其APP与设备是一对一关系，APP就是设备的唯一代理。在工业领域的物联平台中，边缘应用、边缘计算能力更强，其架构形式为：物联管理平台<——>边缘代理<——>设备，物联管理平台直接通信的对象是边缘代理，而非设备！确切的说，是边缘代理上的应用，这些应用中，一部分是与设备一一对应，还有一部分与设备之间并无确切映射关系。因此，个人认为，在工业领域的物联平台中，其“物”的概念应相对于消费物联网进行扩展，不仅包括设备，还包括应用。相同之处在于，物联平台中的物模型本质是描述了平台与设备或者应用之间的交互模型。

物模型的核心

物模型的核心就是交互模型，交互模型主要从逻辑角度描述交互格式，它只描述了应该包含哪些数据，并未描述数据应该如何组织；例如，在同一个物模型文件时，以JSON方式传输一条温度数据：temp=30，具体数据组织方式可以为：
{
“temp”: 30
}
还可以为：
{
“key”: “temp”,
“value”: 30
}
通信模型主要描述交互模型中数据应该如何组织，例如以JSON方式组织，还是以紧凑的0、1格式组织。
简单而言，交互模型相当于语言，通信模型相当于文字，二者不完全相同，例如两个不识字的人可以正常交流，却无法用文字交流。

在具体的企业内部可能会存在一些场景模型，建模的对象不仅是物，还可以是场景，而且针对同一场景，使用角度不同，建模方法也不同。电力、化工等业务的建模中，主要针对各自的业务场景，而不仅仅是某一个特定的边或者端设备，例如化工炼化中，还包括车间、装置与设备之间的关系。因此，各专业提供的模型更应该称之为场景模型，而不是物联管理平台中所提到物模型。场景模型与物模型建模原理相同，但是使用场景和建模对象不同，不能用物模型的规范去套用于场景模型定义中，二者是分别应用于不同场景的建模，可以而且应该同时存在的！
场景模型是各业务系统根据自己业务场景的建模，跟是否采用物联管理平台与设备交互无关；物模型是业务系统采用物联管理平台与物，即设备或APP交互时，所采用的交互约束模型。因此，不能用互联网的物模型规范去约束和指导各业务场景的场景建模，而是在业务系统的场景建模之后，需要通过物联管理平台与物（设备或APP）通信时，约定双方的数据交互格式。物联管理平台提供了报文、文件等多种数据传输方式，各业务系统在制定与设备之间的数据交互格式时，应灵活选择合适的方式交互，例如：边缘代理上的某个app要通过物管平台向应用系统发送一个视频数据，由于视频数据格式难以用物模型来描述，此时可以将之存储为文件，利用物联管理平台文件传输功能完成文件本体传输，然后借助物联管理平台完成文件元信息（文件名、文件大小、MD5值、视频文件的URL等）传输。

为什么要使用物模型？

主要原因在于它能够帮助描述和管理物理世界中的各种设备、传感器和数据，从而实现对物联网设备的统一管理、互操作性和数据标准化：

1. 设备描述和管理：通过定义物模型，可以清晰地描述物联网中的各种设备和传感器，包括其功能、属性、状态和行为等信息。这有助于统一管理和监控不同类型的设备，并为其提供标准化的接口。
2. 互操作性：物模型可以帮助不同厂商的设备之间实现互操作性，因为它们可以基于相同的模型进行交互。这样，不同厂商的设备可以更容易地集成到一个统一的物联网平台中。
3. 数据标准化：通过定义物模型，可以规范物联网设备产生的数据格式和结构，使得不同设备生成的数据具有一致的语义和格式，从而方便数据的处理和分析。
4. 应用开发和集成：基于物模型，开发人员可以更容易地开发应用程序来与物联网设备进行交互，因为他们可以依据标准的模型进行开发，而无需过多关注底层的设备细节。

举例来说，一家智能家居公司可以通过使用物模型来描述各种智能设备（如智能灯泡、智能插座、温度传感器等），并为这些设备定义标准的接口和行为。这样用户可以更轻松地管理和控制这些设备，同时可以让不同厂商的设备无缝集成到他们的智能家居平台中。因此，物模型在物联网中的应用有助于提高设备管理的效率、促进设备之间的互操作性，并为应用开发提供了标准化的基础。

物模型能解决那些行业问题？

目前物联网行业普遍存在着设备孤岛、软硬开发强耦合的问题，需要构建模型统一描述语言、面向物理实体的统一建模，物模型作为物的抽象层屏蔽了底层终端差异，标准化了设备的能力表达和交互方式，极大降低了物联网应用开发和快速复制的成本。

物模型带来什么价值？

• 低门槛接入：提供设备建模和交互协议基础能力。这是最基础的价值，所有设备上云都需要建模和交互协议。物模型和协议设计是否足够专业，这其实是绝大多数中小企业的门槛，他们刚开始意识不到，随意设计，随着规模和业务变化弊端就会体现出来。

• 标准化：物模型作为物联网的抽象层，类似操作系统屏蔽硬件、JVM屏蔽OS的差异性一样，通过标准化设备的能力表达和交互方式，解决了物联网严重碎片化情况下协议差异、软硬开发耦合、全链路验证流程长、设备孤岛、数据孤岛等问题。

• 生态化：软、硬件一旦基于物模型标准化开发和交互，围绕物联网的多角色，包括ISV，SI，IHV等在设备开发、生产、运维、售卖、集成、运行等环节相互之间能够解耦，提升了设备的流通性，促进生态化。

如何设计物模型呢？

大多数对于设备建模都采用的是面向对象语言的思路，面向对象语言的抽象能力在计算机编程发展的几十年已经被证明，我们物模型定义也充分借鉴，却又因物联网而有所不同。我们以面向对象语言java里面的class做类比，class用属性和方法描述对象的状态和行为；物模型也可以用属性和方法来描述物的状态和行为。同时结合设备特性，我们将物模型schema进行了一定的扩展，定义为属性、服务(方法)和事件三要素，事件是一类特殊的属性，比如空调的故障告警，这类属性严重性高，实时性强，一般需要监控并及时响应。为了对设备更精确的描述，物模型针对每种数据类型还定义了非常严谨的数据规范，比如在数据类型之外，还需要定义数据范围、精度、步长等规范。这里提供一个温度传感器物模型示意图：

类型还定义了非常严谨的数据规范，比如在数据类型之外，还需要定义数据范围、精度、步长等规范。这里提供一个温度传感器物模型示意图：