物联网要求和协议

物联网 （IoT） 的高级协议提供了各种特性，使其适用于广泛的应用。例如，SNMP 多年来一直用于管理网络设备和配置网络，而 DDNS 已用于提供对 Web 设备的浏览器访问。任一协议也可用于管理和配置各种家庭设备。相比之下，CoAP 更适合具有微小硬件和完全不同安全性的非常小的传感器部署。有必要对这些协议和应用程序要求进行更深入的了解，以正确选择最适合手头应用程序的协议。

一旦知道正确的协议或几个协议集具有应用程序部署、管理和应用程序支持的正确特性，就应该了解每个协议的最佳实现。根据这种理解，设计人员可以为系统选择每个协议的最佳实现，然后从中选择系统的最佳协议实现。

协议选择问题与协议的实现密切相关，支持协议的组件在最终设计中通常是必不可少的。这使得决定变得非常复杂。部署、 *** 作、管理和安全的所有方面都必须考虑作为协议选择的一部分，包括实施环境。

此外，对于特定的应用并没有任何融合的标准，这些标准一般都是由市场来选择的。这是一个问题也是一个机会，因为今天为应用程序选择的协议在未来可能会过时并且可能需要被替换，或者如果做得正确，可能会成为标准。作为开发人员，使用环境的特定功能来满足系统要求，而这反过来又依赖于协议的细节，这会使将来的更改变得非常困难。

本文研究了可用协议的范围、驱动这些协议特性的具体要求，并考虑了构建完整系统的实现要求。

协议和供应商

物联网的高级协议具有各种特性并提供不同的功能。这些协议中的大多数是由特定供应商开发的，这些供应商通常会宣传他们自己的协议选择，没有明确定义他们的假设，并忽略其他替代方案。出于这个原因，依靠供应商信息来选择物联网协议是有问题的，并且已经产生的大多数比较不足以理解权衡。

物联网协议通常与业务模型绑定。有时这些协议是不完整的和/或用于支持现有的业务模型和方法。其他时候，它们提供了更完整的解决方案，但资源需求对于较小的传感器来说是不可接受的。此外，使用协议背后的关键假设没有明确说明，这使得比较变得困难。

与物联网应用相关的基本假设是：

· 将使用各种无线连接

· 设备范围从微型 MCU 到以小型 MCU 为重点的高性能系统

· 安全是核心要求

· 数据将存储在云端，并可能在云端进行处理

· 需要连接回云存储

· 需要通过无线和有线连接将信息路由到云存储

协议开发人员做出的其他假设需要更深入的调查，并将强烈影响他们的选择。通过查看这些协议的关键特性和关键实现要求，设计人员可以更清楚地了解协议领域和支持特性领域究竟需要什么来改进他们的设计。在我们看这个之前，让我们回顾一下有问题的协议。

物联网或 M2M 协议

对于协议栈中更高级别的 M2M 协议，有一组广泛的协议被提升为物联网通信的灵丹妙药。请注意，这些 IoT 或 M2M 协议侧重于应用程序数据传输和处理。以下列表总结了通常考虑的协议。

· CoAP

· ConTInua – 家庭健康设备

· DDS

· DPWS：WS-Discovery、SOAP、WSAddressing、WDSL 和 XML Schema

· HTTP/REST

· MQTT

· UPnP

· XMPP

· 零MQ

图 1 总结了这些协议的特性。与基础设施和部署相关的几个关键因素将在下面单独讨论。

图 1：如果 POSIX/Linux API 可用，则可以更轻松地支持所有 M2M 或 IoT 协议。Unison OS 配备了物联网协议的关键组合，作为现成的选项，使用它的 POSIX API 来实现快速和简单的设备支持。

关键协议特性

物联网 （IoT） 中的通信基于 Internet TCP/UDP 协议和相关的 Internet 协议进行设置。对于基本通信，这意味着 TCP 流套接字的 UDP 数据报。小型设备的开发人员声称 UDP 在性能和尺寸方面具有很大优势，这反过来又可以最大限度地降低成本。虽然是真的，但在许多情况下并不重要。

流套接字的性能受到影响，但它们确实保证了所有数据的按顺序传递。在 STM32F4 上以 167 MHz 发送传感器数据的性能损失低于 16.7%（使用 2 KB 数据包测量 - 较小的数据包会降低性能损失）。通过采用流套接字的方法，还可以使用标准安全协议来简化环境（尽管如果可用，DTLS 可以与 UDP 一起使用）。

同样，升级到 TCP 的额外 20 KB 闪存和 8 KB RAM 的内存成本差异通常很小。对于微不足道的应用和体积庞大的传感器，这可能很有意义，但通常不会影响 ARM Cortex-M3 及更高版本或其他架构（如 RX、PIC32 和 ARM Cortex-Ax）的设计。

消息传递常见的 IoT 方法非常重要，许多协议已迁移到发布/订阅模型。由于连接和断开连接的节点很多，并且这些节点需要连接到云中的各种应用程序，发布/订阅请求/响应模型具有优势。它动态响应随机开/关 *** 作，并且可以支持许多节点。

CoAP 和 HTTP/REST 两种协议都基于请求响应而没有发布/订阅方法。在 CoAP 的情况下，使用 6LoWPAN 和 IPv6 的自动寻址来唯一标识节点。在 HTTP/REST 的情况下，方法是不同的，因为请求可以是任何东西，包括发布请求或订阅请求，所以事实上，如果以这种方式设计，它就会成为一般情况。今天，这些协议正在合并以提供完整的发布/订阅请求/响应模型。

系统架构多种多样，包括客户端服务器、树形或星形、总线和 P2P。大多数使用客户端-服务器，但其他使用总线和 P2P 方法。星形是一种截断树方法。这些各种架构都存在性能问题，通常在 P2P 和总线架构中可以找到最佳性能。模拟方法或原型方法在设计早期是首选，以防止意外。

可扩展性取决于在现场添加许多节点，并轻松增加云资源以服务这些新节点。各种架构具有不同的属性。对于客户端服务器架构，增加可用服务器池就足够了，而且很容易。对于总线和 P2P 架构，规模是架构中固有的，但没有云服务。在树形或星形连接架构的情况下，可能会出现与在树上添加额外叶子相关的问题，这会给通信节点带来负担。

可扩展性的另一个方面是处理大量变化的节点并将这些节点链接到云应用程序。如前所述，发布/订阅请求/响应系统旨在实现可扩展性，因为它们处理因各种原因离线的节点，这允许应用程序在决定订阅和请求数据时接收特定数据，从而实现精细的数据流控制。 不太健壮的方法几乎不能扩展。

低功耗和有损网络具有打开和关闭的节点。这种动态行为可能会影响整个网络部分，因此协议是为多路径动态重新配置而设计的。ZigBee、ZigBee IP（使用 6LoWPAN）和本机 6LoWPAN 中的特定动态路由协议可确保网络适应。如果没有这些特性，处理这些节点就变成了一种不连续的 *** 作，并且对节点的资源要求更高

随着应用程序数量的增加，资源需求是关键。微控制器以非常低的成本提供智能，并有能力处理上面列出的问题。有些协议太耗费资源，无法在小节点上实用。除非包含大量串行闪存或其他存储介质，否则不连续 *** 作和大数据存储将受到限制。随着资源的增加，为了降低整体系统成本，更有可能添加聚合节点以提供额外的共享存储资源。

互 *** 作性对于未来的大多数设备至关重要。到目前为止，业界已经看到了多套单点解决方案，但最终用户希望传感器和设备能够协同工作。通过使用一组标准化协议以及标准化消息传递，设备可以与支持它们的云服务分离。这种方法可以提供完整的设备互 *** 作性。此外，使用智能发布/订阅选项，不同的设备甚至可以使用相同的云服务，并提供不同的功能。使用开放的方法，应用标准将会出现，但今天 M2M 标准才刚刚出现，应用标准是未来几年的事情。今天，所有主要协议都在标准化。

使用标准信息技术安全解决方案的安全性是大多数提供安全性的协议的核心安全机制。这些安全方法基于：

· TLS

· IPSec/VPN

· SSH

· SFTP

· 安全引导加载程序和自动回退

· 过滤

· HTTPS

· SNMP v3

· 加解密

· DTLS（仅用于 UDP 安全）

由于系统将部署多年，因此将安全作为软件包的一部分进行设计是必不可少的。

实施要求

隐私是一项基本的实施要求。在隐私法的支持下，几乎所有系统都需要与云进行安全通信，以确保无法访问或修改个人数据并消除责任。此外，设备的管理和云中出现的数据需要分开管理。如果没有此功能，用户的关键个人信息将无法得到适当的保护，并且任何拥有管理权限的人都可以使用。

图 2：使用两个独立的后端或云解决方案来分离管理和用户数据是保证用户隐私的首选解决方案。管理系统的计费和应用程序的计费也可以使用这种方法分开管理。

在系统架构图中，我们展示了云内部系统管理和应用程序处理以满足隐私法所需的两个独立组件。这两个组件可能具有单独的计费选项，并且可以在单独的环境中运行。管理站还可能包括：

· 系统初始化

· 远程现场服务选项（如现场升级、重置为默认参数和远程测试）

· 用于计费目的的控制（例如帐户禁用、帐户启用和计费功能）

· 用于盗窃目的的控制（相当于将设备变砖）

鉴于这种类型的架构，还应考虑其他协议和程序：

· 在云系统上定制开发的管理应用程序

· 传感器节点集合的SNMP管理

· 云中的计费集成程序

· 支持使用在 Unison OS 上运行的 SQLite 的不连续 *** 作来存储和选择性地将数据更新到云端

计费是商业系统的一个关键方面。电信运营商已经证明，按月付费模式是最佳的收入选择。此外，用于无缝计费的自动服务选择和集成也很重要。xyk依赖也会产生问题，包括超额问题、过期卡和删除帐户。

自我支持的用户也是实施成功的关键。这包括远程现场服务，因此设备永远不会返回工厂，智能或自动配置，在线帮助，社区帮助和非常直观的产品都是关键。

应用程序集成也很重要。今天点系统占主导地位，但未来的关键是让传感器可用于用户选择的广泛应用。准确性和可靠性会极大地影响结果应用结果，一旦标准接口出现，预计该领域的竞争就会出现。通过服务器的间接访问可确保安全性、无需更改应用程序的演进和计费控制。

非连续运营和大数据齐头并进。随着设备随机连接和断开连接，需要为传感器保存数据并稍后更新云。由于功率和成本原因，存在存储限制。如果某些数据很重要，则可以保存它而丢弃其他数据。可能会保存所有数据，并稍后执行对云的选择性更新。处理数据的算法可以在云或传感器或任何中间节点中运行。所有这些选项都对传感器、云、通信和外部应用程序提出了特殊挑战。

多连接传感器访问也是使传感器真正可用于广泛应用的一项要求。这种连接很可能通过服务器进行，以简化传感器并消除重复消息的电源要求。

Unison OS 的物联网协议

Unison RTOS 针对物联网应用的小型微处理器和微控制器。因此，它提供了设计师期望的许多东西。Unison 的特点包括：

· POSIX API

· 广泛的互联网协议支持

· 各类无线支持

· 远程现场服务

· USB

· 文件系统

· SQLite

· 安全模块

这是对此处讨论的广泛协议集的现成支持和工厂支持的补充。

通过为物联网开发提供一整套功能和模块以及模块化架构，开发人员可以插入他们选择的物联网开发协议。构建协议网关也是可能的。这种方法通过消除锁定和缩短上市时间来最大限度地降低风险。

Unison 还具有可扩展性，使其能够安装到微型微控制器中，并为功能强大的微处理器提供全面支持。内存占用很小，直接导致非常快速的实现。

物联网协议

许多协议被吹捧为理想的物联网 （IoT） 解决方案。通常，正确的协议选择会被在其产品中拥有既得利益的供应商所掩盖。用户必须了解他们的具体要求和限制，并拥有精确的系统规范，以确保为各种管理、应用程序和通信功能选择正确的协议集，并确保满足所有实施规范。

RoweBots Unison RTOS 适合满足物联网需求，具有适用于各种协议的现成模块和一整套支持模块，可实现快速轻松的开发。

审核编辑：郭婷