我们在这里做的事情是，我们试图偶尔评估物联网(IoT)的结构，试图从聚集在一起工作或相互竞争的各种部件中找到意义。我通常尝试将一些混乱归纳或抽象为更广泛的结构，希望更容易解析(或成为一个更容易的入口点)。
我们之前做过，简单地看一下Xively。嗯，另一个机会来了，当时一家叫Zebra的公司联系了我，他们提供了一个叫Zatar的物联网基础设施(不确定是否是来自咱'atar[那个撇号代表了一个不寻常的无法在拉丁文字中表示的咽部]，这将给它一个美味的表面)。我通常的第一个问题是，“这在高层次的计划中处于什么位置?”
Zatar似乎实现了业务对象，尽管它们使用不同的词汇表，将它们对设备的抽象称为“化身”。所以他们看起来比Xively的水平更高。然而，与任何高级实体一样，它是构建在它下面的堆栈上的。他们使用的顶级支持协议之一是OMA的轻量级M2M协议(LWM2M)。
我对LWM2M做了一些简单的研究，我很高兴他们有白皮书，因为他们连一个协议文档都没有。他们有一个章节的集合(几十个)，都是按字母顺序排序的，所以真的很难判断哪一个(如果有的话)是一个顶级文档。我将来可能会更深入地研究这个协议。
但是，在高层次上，通过Zatar和LWM2M，我正在改进我对“业务对象”层的看法。一般来说，这一层是存在特定对象语义的地方:恒温器、门锁和洗衣机。在它下面，只有通用消息存在，其含义对协议是不透明的。
看来LWM2M支持对象的概念，而不需要标准化特定的对象。因此，它允许您创建一个抽象实体，并赋予它属性或交互功能——本质上是一个API——而无需说明具体应该是什么。
Zatar预先配备了一个基本头像，用户可以从中定义自己的特定头像。这无需任何显式编码即可完成。相比之下，其他人(如Ayla Networks，来自不久前)包括预定义对象。因此，我将“业务对象”概念分为两层:通用层和特定层。通用层只是支持业务对象的概念;特定层建立对象的细节。
例如，给定一个通用功能，三家照明公司可以定义三个不同的模型或对象来表示照明，每个模型或对象都遵循通用协议。如果有人想进一步标准化——比如办公室管理人员厌倦了必须弄清楚各种设备遵循哪种照明协议——那么有人可以进一步标准化单一的照明协议;这将是一个特定的标准。
然而，重要的是要记住，LWM2M是协议标准，而Zatar不是;它是一种实现或构建该协议和其他协议的产品。
Zatar的另一个特点是专注于企业。我们已经剥离了一些概念消费者物联网与工业物联网但第三个专业实体——企业物联网的概念，我还没有完全掌握。部分原因是规模问题——拥有大量数据的大型实体必须在全球共享。这需要进一步的行业调查;在接下来的几个月里，请关注这些页面，了解更多关于工业设备的信息低密度聚乙烯表这可以用于业务改进。
最后一点:说这些产品和标准只是实现业务对象是一种严重的过度简化。就像你浏览OMA文档或者Zebra的下图所看到的那样，有很多很多的细节以及支持服务和应用程序都被包裹在其中。对于LWM2M, in包括通过各种网络媒体进行交互的低级概念，以及浏览器应该如何运行。对Zatar来说，有云服务和其他应用程序。我几乎不敢尝试抽象一些潜在的细节。我们将会看到……
同时，您可以了解更多关于Zatar的细节在这里;您可以了解更多关于OMA的LWM2M协议在这里。
