文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

假设你在一个物联网项目的计划阶段。你有很多的抉择要做,也许你不知道从哪开始:

在这篇文章中,我们关注于如何思考这个问题的标准、协议和无线通信的框架。

当然,这个框架取决于你的部署将是对内的(如工厂内)还是对外的(如消费产品)。在这段对话中,我们将着重讨论面向更广泛的客户推出的产品,为此,我们有很多需要考虑的。

让我们看看物联网的现状— 底线,没有一个标准如此完美或重要以至于不使用它就会犯错。那么,我们要做的是尽可能的寻找解决问题的方法(该方法要有可接受的实现成本和规模),而不是过于担心未来流行的标准。

第 1 段(可获 2.26 积分)

因此,首先归根结底是技术的限制:

  • 覆盖范围和带宽需求?
  • 网络中要支持多少个节点?
  • 无线通信的成本?

无线通信的选择有很大的影响—它不仅是你物料清单上一行巨额的项目,它也将决定设备所需的资源。例如,你最终选择WiFi无线通信,那就需要不菲的CPU和内存资源,而如果选择蓝牙或者其他网格网络,就少了很多。 还要考虑到基础设施的扩展成本。如果通过WiFi:正在部署的位置是否已经有WiFi基础设施? 如果我们从头开始,覆盖大面积的计划是什么? 这可能需要巨大的代价,尤其是如果你使用工业级的接入点,所以考虑到这些影响是非常重要的。

第 2 段(可获 2.19 积分)

聚焦具体标准

我们认为我们发现的最大误区: “难道没有一个标准来规整他们吗?“ 那是不可能的,这不仅是因为作为一个行业我们从不会在所有的事情上达成一致,也因为在许多情况下,不同的标准解决不同的问题。所以,理解了这个,我们现在可以看看每个协议要解决的东西以及它们在OSI模型或 "栈"上所处的位置。

MQTT

有些人认为这是一个从设备到服务器通信的完整协议,但并不全是。 MQTT作为一种数据格式用于通信,并且该负载可以通过任意方式传输,可以是Wi-Fi,、网格网络或其它套接字协议。它定义一种方法来处理事物的属性。围绕着属性的读写很好的解决了物联网的问题。在某些方面,它确实节省了开发时间,但这取决于你在多大程度上实现它,它可能会花费你更多的开发时间。一旦你在过它的每个部分,你要认真的做好记录,有时当逼近一个时间和成本因素时,实现自己的负载方案可能是一个更好的选择。

第 3 段(可获 3.04 积分)

它足够丰富到你绝对要使用它吗? 不,它还没有达到那个层度,也不可能达到那个层度。目前它是一个设备直连到云的实用标准, 我们不对两端进行控制,因为它提供了一些我们达成一致的通用语言的处理措施;但要记住的是,大多数时候,它实际上需要附加的文档说明 — 要读/写什么属性以及确切的实现机制 — 这样,到最后你就不会在使用MQTT上花费太多的工夫。

第 4 段(可获 1.3 积分)

ZigbeeZ-wave

同样从网络层开始,Zigbee和Z-wave在网状网络中占有重要的位置。它们试图解决两个问题:提供一个合理的规范,将数据包从网状网络上的一个位置移到另一个位置,并指示应该如何构造这些包;因此,他们在栈中的位置更高。这也是限制他们的地方。 例如,Zigbee使用一个称为profiles的系统,它是一些功能的集合,比如 smart energy profile 或home automation profile。当一个协议要如此具体的指明说‘这是灯泡所做的事情’时,就很难去实现那些未包含在profile中的设备。虽然有自定义数据,但这一点上,你并不真正使用交叉兼容规范 — 只要你使用了未在profile中定义的设备,你就基本上违反了标准。

第 5 段(可获 2.01 积分)

关于这两个的另一个考量是他们都是路由的网状网络。我们使用一个节点与另一个节点进行通信时需要借助中间节点。也就是说,我们可以发送一条消息从A到B到C到D,但实际上,我们是从A发送一条消息到D。作为路由网格,每个节点都知道消息发送所需的路径,但这也带来了相应的内存开销。Z-wave和Zigbee网络理论上支持65,535个节点(地址空间是一个16位的整数)。 实际限制将近数百个节点,因为这些设备通常是低功率、低内存设备。路由也有一定的时间开销,所以大型网状网络可能会对你的用例产生不可接受的延迟。另一个考虑因素,尤其是如果你要推出一个云控制的消费产品,这些网状网络不能直接连接到互联网—他们需要一个中间桥梁(也就是 网关, hub, edge server) 来与云通信。

第 6 段(可获 2.23 积分)

最后需要注意的是,Z-wave只有一个供应商—无线通信由Zensys制造并销售,所以你必须从他们那进行购买。Zigbee有一个认证过程,并且有Atmel、TI等多个无线电供应商。

蓝牙

蓝牙的芯片出货量确实无可匹敌。 2014年超过10,000种不同型号的蓝牙被推出。.在采用方面,除了WiFi,没有能和与之对比的。蓝牙最初是专为‘personal area networks,’设计的,原始标准支持7个并发设备。现在我们有低功耗蓝牙 (BLE),理论上可以有无限多个并发设备。BLE围绕着物联网的挑战做了大量优化。他们重点着眼于通信所需的功耗,考虑了"低功耗"的方方面面,而不只是在无线电方面-- 他们着眼于数据格式,数据包大小,无线传输时间,内存消耗,内存功耗,以及占用的CPU时间,同时考虑整体的BOM成本。例如,他们指出每次无线传输的时间只能到1.5ms。这个一个最佳的时间 — 如果你传输更长的时间,元件升温,从而需要更多的功耗。他们还指出纽扣电池的功率传输更适合用短脉冲而不是连续脉冲。此外,他们对抗WiFi干扰也做了优化,因为这些协议共享相同的无线频段(2.4GHz).

第 7 段(可获 3.44 积分)

然后企业社会责任来了,实现了蓝牙网格标准。 利用BLE携带的所有优点,获得了网状网络的所有好处。 蓝牙网格是洪泛网格,意味着替代了到节点的特定路由,消息在所有节点间不加区分地发送。 这比传播的网格更好,因为没有内存限制。 对于物联网中的许多问题来说,这是一个很好的解决方案,而且在规模上可能是实现最低的成本。

Thread

一个即将到来的标准,建立在与Zigbee广播相同电源的硅片之上。它解决了网状节点无法通过添加IPv6支持直接与云通信的问题,这意味着网络上的节点可以完成合格的互联网请求。这个标准背后有很多的重要性。 Google似乎认为制作自己的协议(称为“Weave”)是非常有趣的。然后是Nest Weave,这是Google Weave的其他版本。就像现在这样,标准需要很长时间才能真正掌握 - 你可以立即看到Thread的故事有点混乱,这不利于它的采用。但它也解决了设备数量少的问题。以传感器为例。做这些低功耗,轻便,低成本,低内存,低处理,相当笨重的设备需要直接互联网请求?使用Thread,每个节点现在都对这个世界知道的更多 - 例如服务器的位置,也许他们不应该关心这些事情,因为不仅要增加设备的要求,而且现在必须在现场更新他们的概率和频率上升了。在实际传感器和其他端点方面,哲学上您希望最小化这些责任,除非需要离线的耐久性,本地处理和决策(特别是雾计算)的特殊情况。

第 8 段(可获 4.35 积分)

当Thread去年宣布其产品认证时,仅提交了30个产品。关于Thread的另一个要注意的事情是,网格IPv6问题已经解决了 - 蓝牙4.2中实际上有一个规范,它将IPv6路由添加到蓝牙,但很少有人在使用它。尽管北欧半导体厂商认为这将是一个重大的事情,并且首先实施了,但它并没有在行业中出现 ——在2014年第四季度,没有人在谈论它。

Thread还做了一件事是它不再定义设备之间如何对话,以及设备如何格式化数据,这样做会使其更具前瞻性。这是Weave技术进来的地方,因为它假设数据应该结构化。所以基本上只有一种方式看待它,就是Weave+Thread = Zigbee / Z波的直接竞争对手。我们还没有看到谷歌以外的任何人主动采取Weave,除了Nest,他们做了一个很好的营销工作,看起来像是在他们被Weave吸引。

 

第 9 段(可获 2.4 积分)

AllJoyn

其他协议呆在堆栈中更高的位置,并且在网络层保持不可知。其中最着名的可能是高通的Alljoyn的努力。他们有Allseen联盟,虽然他们的品牌有点暗淡 - Allplay,AllShare等。我们看到了一些牵引力,但不是一吨 - 它最大的担忧是它是一个真正开放的协议,宽松的定义,你真的不会建立一个完全可以互操作的东西。这对产品团队来说是一个很大的风险。如果世界上没有足够的设备使用这种语言,那我为什么要使用呢?也就是说,LIFX实现了这一点,它对他们来说非常有用,特别是Windows实现它以后。现在它是Windows 10的一部分 - 有一个专门为AllJoyn的东西,它似乎做得很好。 AllJoyn有证据表明,您可以将设备带到不知道任何事物的表格,并获得某种持久的互操作性。但是,一目了然,看起来很复杂 - 授权处理方式和设备需要相互协商的方式。真的没有失败的采纳

第 10 段(可获 2.63 积分)

IEEE的Wi-Fi

IEEE的802.11系列已经称雄于世了。从B到G再到A,如今是AC。802.11真的很擅长更简单的设置和更高的带宽。它并不关注电源消耗,它更关注性能,因为它就是要成为有线的替代品。大约2年前,它们发布了802.11 AH,命名为 HaLow,试图解决电源问题、频率问题和经典的WiFi配对问题。大多数Wi-Fi设备都不是无头的(headless:没有显示和其它的输入),它们拥有丰富的用户界面-这样我们就可以登录并配置WiFi的连接。配对无头设备是一个非常繁琐的过程。对于HaLow,它们解决了两个问题-如何让事情变得更简单,如何降低运行在无线信道上的设备的预期(尤其是电源)。尚不知它能够带来哪种吸引力,但IEEE对于标准的采用有着优秀的跟踪记录。

第 11 段(可获 2.25 积分)

LoRaSIGFOX

更像是: LoRa vs. SIGFOX。我们正在研究的是如何通过这些协议将很远距离的物体连接起来,例如在智慧城市的应用中。LoRaWAN是一个开放协议,它遵循的是自下而上的策略。而SIGFOX是自上而下构建基础架构的,并且将API交付给其客户。这样说来,SIGFOX更像是一个服务。随着有更多公共类型的应用开始使用IoT,我们能够看到这两个协议之间的舞蹈还是蛮有趣的。

以上就是需要提及的一些标准协议。还有很多很多,但是对于今天的IoT来说,我们并没有看到它们怎么令人激动人心。

第 12 段(可获 1.44 积分)

文章评论