AIOT

使用 TSL 描述的物联网中的实体模型，就是“物模型”也称产品模型、数据模板。

物模型是物理世界的实体东西的一个抽象，是进行数字化描述后，用于数字世界的数字模型。抽象就是要提取出产品的共同特征，形成模型。以智能灯为例，不同的灯，尽管规格不同，但它们的属性是相似，比如都有开关状态的属性，功能逻辑也相仿。我们可以将这些特征标准化，形成智能灯的物模型。 反过来，物模型也规约了设备的功能。新增加的设备，如果是同一类型的，在设计、研发中，会遵循相同的功能定义，有相同的特征，实现相同的服务。比如，灯都应该有“开”和“关”两种状态。

基于共同的抽象特征，物模型可以让应用程序不再针对一个个的产品设备，而是同一类设备采用相同的处理逻辑。这实际上是应用开发的基础。当烟感传感器的数值触发报警时，即使是不同品牌的烟感产品，应用程序也可以对数值做相同的处理和判断，否则只能分别进行数值分析。 另外，物模型中，设备的功能是明确定义的，可以方便地实现场景联动。比如，光线传感器可以基于光照强度，向智能电灯发送亮度的控制命令，或者开和关的命令。

我们知道，智能电灯的状态，要么是打开，要么是关闭；当进行控制时，这两种状态还会相互转换。此外，有些灯还可以根据需求设置不同的亮度、颜色和色温等。 属性的特点是可读可写。也就是说，应用程序可以读取属性，也可以设置设备的属性。我们还可以看到类似的例子，比如环境监测设备的温度、湿度这两个属性等。

如果智能电灯在运行过程中，出现了低电压的情况，或者发生了硬件故障，那么联网的设备可以将这些信息发送出去，通知你来及时作出处理。 一个事件可以包含多个输出参数。事件不同于属性，事件是设备上报的，不能由应用来设置。类似的例子，还有某任务完成时的消息，环境传感器检测到污染物的告警等。

我们再看生活中关于灯的一个使用场景：第一次约会的时候，你希望灯能够烘托出浪漫的气氛，就要调节灯的颜色、亮度和色温。如果分别设置属性，将会非常繁琐，这时你会想到要为灯增加一个场景模式的功能，一个命令就可以设置到浪漫模式。 这种设备 动作由应用下发给设备，设备可以返回结果给应用。从执行的流程看，动作还可以进一步分为同步和异步。这取决于动作是否是个耗时的操作，以及其他应用逻辑对于动作执行结果的依赖关系。

和编程语言一样，作为一种模型语言，物模型的数据也有不同的数据类型。它们主要包括六种： 布尔型（Bool）：非真即假的二值型变量。例如，开关功能只有开、关两种状态。 整数型（Int）：可用于线性调节的整数变量。例如，电灯的亮度是一个整数范围。 字符串型（String）：以字符串形式表达的功能点。例如，灯的位置。 浮点型（Float）：精度为浮点型的功能点。例如，电压值的范围是 0.0 - 24.0。 枚举型（Enum）：自定义的有限集合值。例如，灯的颜色有白色、红色、黄色等。 时间型（Timestamp）：String 类型的 UTC 时间戳。 对于整数型、浮点型的数值，它们的单位可以是百分比、电压、米等。 物模型一般是用 JSON 格式来表述模型元素。JSON 是 Web 开发中，经常使用的数据格式，相比于 XML，它更加简洁、清晰，也更轻量级。

按照属性、事件、动作 / 服务这三个要素，一起看看如何用 JSON 格式来定义智能电灯的物模型吧。

智能电灯的开关属性是布尔类型，是必须有的属性。它可以通过 JSON 表述如下：

创建模型的时候，有拷贝和继承两种模式，这两种创建模式的不同主要体现在模型关系上。

**“拷贝”**模式类似于编程语言中的值拷贝，新建模型与被拷贝模型有完全相同的三元素，两个模型相互独立，模型变更互不影响。

**“继承”**模式就是面向对象编程中的继承概念，新建模型被定义为“子模型”，被继承的模型定义为“父模型”。 继承的具体特征是： 1.子模型继承父模型的所有要素，且继承的元素无法被修改。 2.子模型可以再被继承，支持多层的继承关系。 3.子模型可以创建独立的要素，但子模型中新增的要素不可以和所有上级父模型中的元素重名。 4.当父模型中的元素发生变更时，子模型中继承自父模型的元素同步变更，保持与父模型一致。

以我们刚刚定义的智能电灯的物模型为例，如果要增加安装位置的属性，可以继承已有的模型，然后再增加安装位置的属性。（注意：下面的 JSON 表述省略了与父模型重复的内容。）

学习笔记总结自‘物联网开发实战’–郭朝斌 –笔记只用于学习交流，请不要用于商业用途。