电子工程师和物联网（IoT）的产品和系统的应用程序开发人员都有一个几乎令人迷惑的连接选项。

许多通信技术是众所周知的，如WiFi，蓝牙，ZigBee和2G / 3G / 4G蜂窝，但也有几个新兴的新兴网络选项，如线程作为家庭自动化应用的替代品，以及在主要城市实施的空白电视技术用于更广泛的基于IoT的用例。根据应用，范围，数据要求，安全性和功率需求以及电池寿命等因素将决定某种形式的技术组合的选择。这些是向开发人员提供的一些主要通信技术。

蓝牙

重要的短距离通信技术当然是蓝牙技术，在计算和许多消费品市场中已经变得非常重要。预计这是可穿戴产品的关键，特别是连接到物联网，尽管可能通过智能手机在许多情况下。新的蓝牙低功耗（BLE）或蓝牙智能（如现在已被标注）是物联网应用的重要协议。重要的是，虽然它提供了与蓝牙类似的范围，但它的设计旨在显着降低功耗。

但是，Smart / BLE并不是真正设计用于文件传输，更适合于小块数据。鉴于其在智能手机和许多其他移动设备上的广泛集成，因此在许多竞争技术的个人设备环境中肯定具有重大优势。根据蓝牙SIG，超过90％的蓝牙智能手机，包括iOS，Android和Windows的型号，预计到2018年将“智能就绪”。

使用蓝牙智能功能的设备包含了基于射频收发器，基带和协议栈的基本数据速率和低能量核心配置的蓝牙核心规范版本4.0（或更高版本 - 2014年底最新版本4.2） 。重要的是，版本4.2通过其互联网协议支持配置文件将允许蓝牙智能传感器通过6LoWPAN连接直接访问互联网（下面更多）。这种IP连接使得可以使用现有的IP基础设施来管理蓝牙智能边缘设备。有关蓝牙4.2的更多信息，可从RS获得各种蓝牙模块。

标准：蓝牙4.2核心规格

频率：2.4GHz（ISM）

范围：50-150米（智能/ BLE）

数据速率：1Mbps（智能/ BLE）

Zigbee

ZigBee像蓝牙一样具有大量的操作基础，尽管传统上在工业环境中也是如此。 ZigBee PRO和ZigBee远程控制（RF4CE）以及其他可用的ZigBee配置文件均基于IEEE802.15.4协议，该协议是以2.4GHz为目标的行业标准无线网络技术，针对的应用程序需要相对不频繁的数据交换，在限制区域内的距离在100米范围内，例如在家庭或建筑物中。

ZigBee / RF4CE在复杂系统中具有一些显着的优势，提供低功耗操作，高安全性，鲁棒性和高可扩展性，具有高节点数量，并且有能力利用M2M和IoT应用中的无线控制和传感器网络。 ZigBee的最新版本是最近推出的3.0版本，它基本上是将各种ZigBee无线标准统一为单一标准。 ZigBee开发的示例产品和套件包括TI的CC2538SF53RTQT ZigBee片上系统集成电路和CC2538 ZigBee开发套件。

标准：基于IEEE802.15.4的ZigBee 3.0

频率：2.4GHz

范围：10-100米

数据速率：250kbps

Z波

Z-Wave是一种低功耗射频通信技术，主要用于诸如灯控制器和传感器之类的产品的家庭自动化。针对数据速率高达100kbit / s的小数据数据包的可靠和低延迟通信进行了优化，其工作在1GHz频段，并且不受WiFi和其他无线技术在2.4 GHz范围内的干扰，如蓝牙或ZigBee。它支持全网状网络，而不需要协调器节点，并且是非常可扩展的，可以控制多达232个设备。 Z-Wave使用比其他一些更简单的协议，可以实现更快更简单的开发，但与其他无线技术（如ZigBee等）的多种来源相比，唯一的芯片制造商是Sigma Designs。

标准：Z-Wave Alliance ZAD12837 / ITU-T G.9959

频率：900MHz（ISM）

范围：30m

数据速率：9.6 / 40 / 100kbit / s

6LowPAN

基于IP（Internet Protocol）的技术是6LowPAN（IPv6低功率无线个人区域网络）。 6LowPAN不是像蓝牙或ZigBee这样的IoT应用协议技术，而是一种定义封装和头压缩机制的网络协议。该标准具有频带和物理层的自由度，也可以在多种通信平台上使用，包括以太网，Wi-Fi，802.15.4和sub-1GHz ISM。一个关键的属性是IPv6（互联网协议版本6）堆栈，这是近年来非常重要的介绍，以实现物联网。 IPv6是IPv4的后继者，为世界上每个人提供大约5 x 1028个地址，使世界上任何嵌入式对象或设备都拥有自己的唯一IP地址并连接到互联网。例如，IPv6专为家庭或楼宇自动化设计，提供了一种基本的传输机制，可以通过低功耗无线网络以成本效益的方式生产复杂的控制系统和与设备进行通信。

该标准旨在通过基于IEEE802.15.4的网络发送IPv6数据包，并实施开放IP标准，包括TCP，UDP，HTTP，COAP，MQTT和Websockets，该标准提供端对端可寻址节点，允许路由器将网络连接到IP。 6LowPAN是一种网状网络，具有强大的可扩展性和自愈性。网状路由器设备可以路由指定给其他设备的数据，而主机能够长时间睡眠。这里有6LowPAN的解释，TI提供。

标准：RFC6282

频率：（适用于各种其他网络媒体，包括蓝牙智能（2.4GHz）或ZigBee或低功率射频（亚1GHz）

范围：N / A

数据速率：N / A

线程

线程是一种针对家庭自动化环境的新型基于IP的IPv6网络协议。基于6LowPAN，也喜欢它，它不是像蓝牙或ZigBee这样的IoT应用协议。然而，从应用的角度来看，它主要被设计为WiFi的补充，因为它识别出WiFi对于许多消费者设备而言是有利的，它在家庭自动化设置中使用的限制。

线程组于2014年中推出，免版税协议基于各种标准，包括IEEE802.15.4（作为无线空中接口协议），IPv6和6LoWPAN，并为物联网提供了一种弹性的基于IP的解决方案。 Thread专为从现有的IEEE802.15.4无线芯片供应商（如飞思卡尔和Silicon Labs）工作，Thread支持使用IEEE802.15.4无线电收发器的网状网络，能够处理多达250个具有高级别身份验证和加密的节点。相对简单的软件升级应允许用户在现有的支持IEEE802.15.4的设备上运行线程。

标准：线程，基于IEEE802.15.4和6LowPAN

频率：2.4GHz（ISM）

范围：N / A

数据速率：N / A

无线上网(WIFI）

WiFi连接通常是许多开发人员的明显选择，特别是考虑到局域网内家庭环境中WiFi的普及。除了明确指出，现有基础架构广泛，并提供快速的数据传输和处理大量数据的能力，这不需要进一步的解释。

目前，在家庭和许多企业中使用的最常见的WiFi标准是802.11n，其提供了在数百兆比特每秒的严格吞吐量，这对于文件传输是很好的，但对于许多IoT应用来说可能太耗电了。 RS提供了一系列用于构建基于WiFi的应用的RF开发套件。

标准：基于802.11n（今天最常见的用途）

频率：2.4GHz和5GHz频段

范围：约50m

数据速率：最大600 Mbps，但根据所使用的通道频率和天线数量（最新的802.11-ac标准应提供500Mbps至1Gbps），150-200Mbps更为典型。

蜂窝

需要更长距离运行的IoT应用程序可以利用GSM / 3G / 4G蜂窝通信功能。虽然蜂窝电话显然能够发送大量的数据，特别是对于4G，但对于许多应用来说，费用和功耗将会太高，但是对于传输速度非常低的基于传感器的低带宽数据项目来说，这是非常理想的互联网上的数据量。该领域的一个关键产品是SparqEE系列产品，包括原始的小型CELLv1.0低成本开发板和一系列与Raspberry Pi和Arduino平台一起使用的屏蔽连接板。

标准：GSM / GPRS / EDGE（2G），UMTS / HSPA（3G），LTE（4G）

频率：900/1800/1900 / 2100MHz

范围：GSM最大35km; HSPA最长200公里

数据速率（典型下载）：35-170kps（GPRS），120-384kbps（EDGE），384Kbps-2Mbps（UMTS），600kbps-10Mbps（HSPA），3-10Mbps

NFC

NFC（近场通信）是一种技术，能够实现电子设备之间的简单和安全的双向交互，特别适用于智能手机，允许消费者执行非接触式支付交易，访问数字内容和连接电子设备。本质上它扩展了非接触式卡技术的能力，并使设备能够在距离小于4cm的情况下共享信息。此处提供更多信息。

标准：ISO / IEC 18000-3

频率：13.56MHz（ISM）

范围：10厘米

数据速率：100-420kbps

Sigfox

标题另一种广泛的技术是Sigfox，它的范围在WiFi和蜂窝之间。它使用可免费使用的ISM频带，而不需要获取许可证，以便在非常窄的频谱范围内将数据传输到连接对象和从连接对象传输数据。 Sigfox的想法是，对于运行在小型电池上的许多M2M应用程序，只需要低级别的数据传输，则WiFi的范围太短，而蜂窝电话太贵，并且功耗太大。 Sigfox使用一种称为超窄带（UNB）的技术，仅用于处理每秒10至1,000位的低数据传输速度。与5000微瓦相比，蜂窝通信消耗的电量仅为50微瓦，或者可以通过2.5Ah电池提供典型的待机时间20年，而蜂窝电话仅为0.2年。

已经部署在成千上万个连接对象中，该网络目前正在欧洲主要城市推出，其中包括英国的十个城市。该网络提供了一个强大的，功率高效和可扩展的网络，可以与数百万个电池供电设备在几平方公里的区域进行通信，使其适用于预期包括智能电表，病人监视器，安全设备，街道照明和环境传感器。 Sigfox系统使用Silicon Labs等EZRadioPro无线收发器等硅片，为在1GHz以下频段工作的无线网络应用提供行业领先的无线性能，扩展范围和超低功耗。

标准：Sigfox

频率：900MHz

范围：30-50公里（农村环境），3-10公里（城市环境）

数据速率：10-1000bps

Neul

与Sigfox相似，在1GHz频段内运行，Neul利用电视白空间频谱的小片，提供高可扩展性，高覆盖率，低功耗和低成本无线网络。系统基于Iceni芯片，其使用白色空间无线电进行通信，以访问高质量的UHF频谱，由于模拟到数字电视转换，现在可用。通信技术称为无重量，是一种为IoT设计的新型广域无线网络技术，与现有的GPRS，3G，CDMA和LTE WAN解决方案大有竞争。数据速率可以是在同一个单一链路上从每秒几位到100kbps的任何数据速率;并且设备可以从2xAA电池消耗少至20至30mA，这意味着在现场10至15年。

标准：Neul

频率：900MHz（ISM），458MHz（英国），470-790MHz（白色空间）

范围：10公里

数据速率：最少可达100kbps

LoRaWAN

Again在某些方面与Sigfox和Neul类似，LoRaWAN针对广域网（WAN）应用，旨在为具有特定功能的低功率WAN提供支持，以便在IoT，M2M和M2M中支持低成本移动安全双向通信智能城市和工业应用。针对低功耗优化并支持具有数百万和数百万台设备的大型网络，数据速率范围为0.3 kbps至50 kbps。

标准：LoRaWAN

频率：各种

范围：2-5公里（城市环境），15公里（郊区环境）

数据速率：0.3-50 kbps。

在之前关于我们的示例保险公司ArchiSurance的“数字客户亲密度”战略的博客中，我们概述了他们打算使用更详细的客户数据来改善客户互动和满意度，并确定定制的保险费。 为此，他们希望使用物联网，从智能互联设备获取数据，如个人健身追踪器，车辆中的黑匣子，家庭自动化网关，车队管理系统，店内RFID设备或智能建筑传感器。

下图显示了他们的意图; 个人客户的保险费部分取决于他们从不同设备获得的数据。 处理此数据以创建客户特定的配置文件，这些配置文件输入到其保险费的计算中。 在总体水平上，这些数据还用于开发新型保险产品，并评估和调整公司的整体风险敞口。

为了支持这一点，ArchiSurance建立了一个数据采集网关，可以连接到生成相关数据的各种智能设备。 这些设备在新的ArchiMate 3.0标准中被建模为设备。 反过来，设备可以位于设施; 在下面的例子中，我们看到家庭报警系统和智能恒温器作为智能家居的一部分。 最后，智能恒温器本身连接到能量网络，模拟为ArchiMate中的分配网络。

ArchiSurance数据采集的实施基于微服务架构。 物联网设备可以通过REST API向网关注册自己。 它还使用API上的服务来通知网关它获取的数据。 该网关由平台即服务（PaaS）支持，为部署，集成，服务生命周期管理，会计，安全性，负载平衡，存储，虚拟化等提供服务。 对于每个已注册的设备，数据获取功能的实例将在容器中运行。 请注意，在体系结构模型中，我们通常不会描述设备的各个实例，而是专注于它们的类型。 如图3所示，它还展示了ArchiMate 3.0的改进分组概念，该概念聚合了其内容并允许与组之间的关系。

这些示例显示了物理和信息技术（现在由ArchiMate 3.0支持）之间的集成如何用于模拟物联网，工业4.0和云计算等创新技术。 BiZZdesign Enterprise Studio支持的不同模型内部和之间的完全可追溯性将允许您将这些技术与其支持的业务流程和产品相关联，并从那里与组织的战略功能，业务成果和业务模型相关联。 这使您可以非常了解创新对您组织的潜在机会和战略影响。

在以后的博客中，我们将展示更多此类示例。 请继续关注更多！

 

原文：https://bizzdesign.com/blog/archimate-3-0-internet-of-things/

本文：http://pub.intelligentx.net/iot-archimater-30-internet-things

讨论： 请加入知识星球【首席架构师圈】

INTERNET OF THINGS

IEEE标准协会（IEEE-SA）认识到物联网对工业的价值以及这项技术创新给公众带来的好处，这些标准，项目和事件与创造充满活力的物联网所需的环境直接相关。 该领域为与物联网有关的所有事物提供参考。

---

IEEE-SA IoT Ecosystem Study

IEEE-SA吸引了世界重点地区的利益相关者，创建了一个物联网生态系统研究。 该研究包括市场，技术和标准三个主要领域，以及对学术研究的作用和用户接受的重要性的考察。 该研究的执行摘要可用。

---

IEEE P2413, Draft Standard for an Architectural Framework for the Internet of Things Working Group

该标准草案定义了物联网（IoT）的架构框架，包括各种IoT域的描述，IoT域抽象的定义以及不同IoT域之间的共同点的识别。 要参与本标准的开发，请访问IEEE P2413工作组页面。

物联网相关标准

以下是与物联网有关的IEEE标准的部分列表。

IEEE 754™-2008 - IEEE浮点算法标准

IEEE 802.1AS™-2011 - 本地和城域网的IEEE标准 - 桥接局域网中时间敏感应用的时序和同步

IEEE 802.1Q TM -2011 - 用于本地和城域网的IEEE标准 - 媒体访问控制（MAC）桥接和虚拟桥接局域网

IEEE 802.3™-2012 - IEEE标准以太网

IEEE 802.3.1™-2011 - 以太网管理信息库（MIB）定义的IEEE标准

IEEE 802.11™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第11部分：无线局域网媒体访问控制（MAC）和物理层（PHY）规范修订10网状网络

IEEE 802.11ad™-2012 - 用于本地和城域网的IEEE标准 - 具体要求 - 第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范 - 修订3：60 GHz中极高吞吐量的增强带

IEEE 802.15.1™-2005 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求。 - 第15.1部分：无线个人局域网（WPAN）的无线介质访问控制（MAC）和物理层（PHY）规范

IEEE 802.15.2™-2003 - IEEE推荐的信息技术实践 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.2节：无线个人区域网络与其他无线设备共存在非授权频带

IEEE 802.15.3™-2003 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.3节：高速率无线的无线媒体接入控制（MAC）和物理层（PHY）规范个人区域网络（WPAN）修订1：Mac子层

IEEE 802.15.3c™-2009 - IEEE信息技术标准 - 本地和城域网 - 具体要求 - 第15.3部分：修正2：基于毫米波的替代物理层扩展

IEEE 802.15.4™-2011 - 用于本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）

IEEE 802.15.4e™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订1：MAC子层

IEEE 802.15.4f™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订2：有源射频识别（RFID）系统物理层（PHY）

IEEE 802.15.4g™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订3：低数据速率，无线的物理层（PHY）规范智能计量公用事业网络

IEEE 802.15.4j™-2013 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求 - 第15.4节：低速率的无线介质访问控制（MAC）和物理层（PHY）规范无线个人局域网（WPAN）修订：替代物理层扩展，支持在2360-2400 MHz频带内运行的医疗身体局域网（MBAN）业务

IEEE 802.15.5™-2009 - 信息技术推荐实践 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.5节：无线个人区域网络中的网状拓扑能力（WPAN）

IEEE 802.15.6™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求 - 第15.6节：无线个人无线介质访问控制（MAC）和物理层（PHY）规范在身体内或周围使用的区域网络（WPAN）

IEEE 802.15.7™-2011 - 本地和城域网的IEEE标准 - 第15.7节：使用可见光的短距离无线光通信

IEEE 802.16™-2012 - IEEE宽带无线接入系统空中接口标准

IEEE 802.16p™-2012 - IEEE宽带无线接入系统空中接口标准修订：对机器到机器应用的增强

IEEE 802.16.1b™-2012 - 用于宽带无线接入系统的无线高级空中接口的IEEE标准 - 修订：对机器到机器应用的增强

IEEE 802.22™-2011 - IEEE信息技术标准 - 系统之间的电信和信息交换无线区域网络（WRAN） - 具体要求第22部分：认知无线RAN媒体接入控制（MAC）和物理层（PHY）规范：电视频道的运作政策和程序

IEEE 802.22.1™-2010 - 信息技术IEEE标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第22.1部分：为在电视中运行的低功率许可设备增强有害干扰保护的标准广播频带

IEEE 802.22.2™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第22.2部分：IEEE 802.22系统的安装和部署

IEEE 1284 TM -2000 - 用于个人计算机的双向并行外围接口的IEEE标准信令方法

IEEE 1285 TM -2005 - 可扩展存储接口的IEEE标准（S / SUP 2 / I）

IEEE 1301.3™-1992 - 用于微型计算机的公制设备实践的IEEE标准 - 带2.5mm连接器的对流冷却

IEEE 1377™-2012 - 用于实用工业计量通信协议应用层（终端设备数据表）的IEEE标准

IEEE 1394™-2008 - 用于高性能串行总线的IEEE标准

IEEE 1451.0™-2007 - 用于传感器和执行器智能传感器接口的IEEE标准 - 通用功能，通信协议和传感器电子数据表（TEDS）格式

IEEE 1547™-2003 - IEEE电力系统互连分布式资源标准

IEEE 1547.1 TM -2005 - 用于将分布式资源与电力系统相互连接的IEEE标准一致性测试程序

IEEE 1547.2™-2008 - IEEE Std 1547™IEEE应用指南，IEEE电力系统分配资源互连标准

IEEE 1547.3™-2007 - IEEE电力系统互连监控，信息交换和分布式资源控制指南

IEEE 1547.4™-2011 - IEEE电力系统分布式资源岛系统设计，运行和集成指南

IEEE 1547.6™-2011 - IEEE分布式资源与电力系统分配二级网络互连的推荐做法

IEEE 1609.2™-2013 - 车载环境中的无线接入IEEE标准 - 应用和管理消息的安全服务

IEEE 1609.3™-2010 - IEEE车载环境无线接入标准（WAVE） - 网络服务

IEEE 1609.4™-2010 - IEEE车载环境无线接入标准（WAVE） - 多通道操作

IEEE 1609.11™-2010 - 车载环境无线接入IEEE标准（WAVE） - 智能交通系统（ITS）的空中电子支付数据交换协议

IEEE 1609.12™-2012 - 车载环境中的无线接入IEEE标准（WAVE） - 标识符分配

IEEE 1675™-2008 - 电力线硬件宽带IEEE标准1900.1-2008 IEEE标准动态频谱接入定义和概念：与新兴无线网络，系统功能和频谱管理有关的术语

IEEE 1701™-2011 - 用于光端口通信协议的IEEE标准，用于补充实用工业终端设备数据表

IEEE 1702™-2011 - 用于电话调制解调器通信协议的IEEE标准，用于补充实用工业终端设备数据表

IEEE 1703™-2012 - 用于局域网/广域网（LAN / WAN）节点通信协议的IEEE标准，以补充实用工业终端设备数据表

IEEE 1775™-2010 - 电力线通信设备IEEE标准 - 电磁兼容性（EMC）要求 - 测试和测量方法

IEEE 1815™-2012 - IEEE电力系统标准通信 - 分布式网络协议（DNP3）2200-2012 IEEE标准协议，用于媒体客户端设备中的流管理

IEEE 1888™-2011 - 用于无处不在的绿色社区控制网络协议的IEEE标准

IEEE 1900.1 TM -2008 - 用于动态频谱接入的IEEE标准定义和概念：与新兴无线网络有关的术语，系统功能和频谱管理

IEEE 1900.2™-2008 - IEEE推荐的无线电系统带内和相邻频带干扰与共存分析的实践

IEEE 1900.4™-2009 - IEEE建筑构架标准，为非均匀无线接入网络中优化的无线电资源使用实现网络设备分布式决策

IEEE 1900.4a™-2011 - IEEE建筑构架标准为异构无线接入网络中优化的无线电资源使用实现网络设备分布式决策修订1：白色空间频段中动态频谱接入网络的架构和接口

IEEE 1901™-2010 - IEEE电力线网络宽带标准：介质访问控制和物理层规范

IEEE 1902.1™-2009 - IEEE标准的长波无线网络协议

IEEE 1905.1 TM -2013 - 用于异构技术的融合数字家庭网络IEEE标准

IEEE 2200™-2012 - 媒体客户端设备中流管理的IEEE标准协议

IEEE 2030™-2011 - IEEE电力系统（EPS），终端应用和负载能源技术与信息技术操作智能电网互操作指南

IEEE 2030.5™-2013 - IEEE采用Smart Energy Profile 2.0应用协议标准

IEEE 11073-00101™-2008 - IEEE卫生信息学标准 - PoC医疗设备通信 - 第00101部分：指南 - 使用射频无线技术的指南

IEEE 11073-10102™-2012 - IEEE健康信息标准 - 医疗器械通讯点 - 命名 - 注释心电图

IEEE 11073-10103™-2012 - IEEE健康信息标准 - 医疗器械通信点 - 术语 - 可植入器件，心脏

IEEE 11073-10201™-2004 - IEEE健康信息标准 - 医疗器械通信点 - 第10201部分：域信息模型

IEEE 11073-10404™-2010 - IEEE健康信息标准 - 个人健康设备通信第10404部分：设备专用 - 脉搏血氧仪

IEEE 11073-10406™-2011 - IEEE健康信息标准 - 个人健康设备通信第10406部分：设备专业化 - 基本心电图仪（ECG）（1到3导联ECG）

IEEE 11073-10407™-2010 - IEEE健康信息标准个人健康设备通信第10407部分：设备专业化血压计

IEEE 11073-10408™-2010 - IEEE健康信息标准个人健康设备通信第10408部分：设备专用温度计

IEEE 11073-10415™-2010 - IEEE健康信息标准个人健康设备通信第10415部分：设备专用称重标尺11073-10420-2010 IEEE健康信息标准 - 个人健康设备通信第10420部分：设备专业化 - 身体成分分析仪

IEEE 11073-10417™-2011 - IEEE健康信息标准个人健康设备通信第10417部分：设备专业化葡萄糖计

IEEE 11073-10418™-2011 - IEEE健康信息标准 - 个人健康设备通信 - 设备专业化 - 国际标准化比率（INR）监测

IEEE 11073-10420™-2010 - IEEE健康信息标准 - 个人健康设备通信第10420部分：设备专业化 - 身体成分分析仪

IEEE 11073-10441™-2008 - IEEE健康信息学标准 - 个人健康设备通信 - 第10441部分：设备专业化 - 心血管健康和活动监测

IEEE 11073-30300™-2004 - IEEE健康信息标准 - 医疗器械通信点 - 运输配置文件 - 红外线

IEEE 11073-30400™-2010 - IEEE卫生信息标准 - 医疗器械通信点第30400部分：接口配置文件 - 电缆以太网

IEEE 14575™-2000 - 用于异构互连（HIC）的IEEE标准（用于并行系统构建的低成本，低延迟可伸缩串行互连）

IEEE 21450™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 通用功能，通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-1™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第1部分：网络能力应用处理器（NCAP）信息模型

IEEE 21451-2™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第2部分：传感器到微处理器通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-4™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第4部分：混合模式通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-7™-2011 - 用于传感器和执行器的智能传感器接口IEEE标准 - 射频识别（RFID）系统的传感器通信协议和传感器电子数据表格式

为什么我们不用c++重写我们的物联网应用程序

这是关于我们dwell如何在Rust中重写他们的物联网网关软件的系列文章的第2部分。这个系列从这里开始，下一章在这里。

我本来打算写为什么我们在dwell不选择c++来重写物联网，但后来我意识到还有一个更广泛的问题需要讨论。我想把这个决定放在历史上我们所有的错误代码的背景下，作为一个物种。在80年代和90年代，我们使用了普罗米修斯的天赋——C语言来为世界各地的每个嵌入式系统编写软件。我们所能完成的事情是没有限制的。但很多我们当时认为很聪明的做法，现在回想起来显然是糟糕的习惯。这些熟悉的错误在几十年后继续造成痛苦和破坏。我将提出我在C和c++的产品代码中看到的一些无可争辩的可怕的东西。我将讨论我所犯过和看到过的错误，在下一章中，我们将讨论简单的语言选择如何彻底地消除大量错误，同时仍然给我们足够的灵活性来编写低级软件。

我们本可以用c++重写我们的物联网平台应用程序。它检查了所有的箱子。这对我来说很熟悉，甚至很容易。但这也会让我或其他人很容易犯错误。使用C就像用蜡烛来照明。它的基本特性是众所周知的，它从人类文明开始就存在了，如果你滥用它，它会点燃你周围的房子。(在这个比喻中，c++是“所有可以被点燃产生光的事物的集合”。)

在过去的30年里，我读了很多糟糕的代码。我也写了不少。没有人是完美的程序员，我们应该选择能够反映这种谦逊的工具。让我们看看您是否熟悉这些陷阱。

神秘指针参数

void myfunc(char* c);
char c;
myfunc(&c);

myfunc的参数是输入吗?一个输出?都有?它实际上是一个以空结尾的数组吗?所有的代码路径都初始化传递的值吗?myfunc segfault如果我传递它为空?函数会保留我传入的指针并在以后使用它吗?查看函数定义并确定它将做什么是不可能的，因为它允许做很多事情。对于小程序来说，这有点烦人。对于拥有超过12个函数的程序，很快就不可能推断出程序的正确性，我们不得不依赖API文档。我们都知道，文档总是正确和最新的。

我敢肯定，你们当中的学究们都在对监视器大喊:如果指针参数只是作为输入，那么签名应该采用const指针。虽然这是正确的，但我从未使用过正确且一致声明参数为const的遗留代码库。(注意:我不确定这是因为古代的编译器不支持const关键字，还是因为在过去的几十年里，一些集体的关节炎让输入这些额外的字符变得很痛苦。无论如何，这在旧代码中很常见。)

Const正确性仍然没有解决房间里的另一个大象……

空指针

const char* foo = 0; /* I remembered to initialize my variable! */
printf(foo);

我将假设您已经读过关于十亿美元错误的文章，并且您已经在您的编程经验中看到过“Segmentation Fault”或“NullPointerException”。如果还没有，请点击上面的链接。我还会在这里。

回来了吗?太棒了。

我要在这里说:托尼·霍尔爵士不仅才华横溢，而且非常谦虚。很少有计算机科学家或软件工程师会直截了当地承认一个设计决策是错误的。不幸的是，这个起源于20世纪60年代的错误非常普遍，我相信许多人看到上面的代码时会想，“编译器会警告您，有什么大不了的?”

当你在8个不同的文件中通过10个不同的函数从A到B到C传递指针参数时，问题就来了，对于编译器(或审阅者)来说，你刚刚在函数上下文之间传递了空指针或未初始化的指针并不是很明显。

您没有在运行时检查每个函数条目是否有非零指针，我没有，标准库肯定也没有。我们不要自欺欺人了。

好吧，让我们使用c++引用

#include <string>bool isEqualToLast(const std::string& s) {
  static const char * last = "";
  bool foo = s.compare(last) == 0;
  last = s.c_str();
  return foo;
}

这段代码在GCC 8上使用-Wextra编译时没有警告，我们正确地使用了const，并且知道参数指向真实数据。只要每个参数都是静态分配的，或者是堆分配的，而不是提前释放，它就可以正常工作。无Bug，直到您使用堆栈变量调用它一次后调用为止。

隐式投射的缺陷（Implicit Cast Bugs）

char data[ENORMOUS_BUF_SZ];
for (int i = 0; i < sizeof(data); ++i) {
/* do stuff */
}

C语言中最具创新性的概念之一是类型系统。每个表达式都有一个类型，例如，如果在需要整数的地方尝试使用字符数组，就会得到一个编译错误。这通常可以防止您犯严重的错误，比如混淆函数参数的顺序。然而，编译器有时会通过静默地将8位类型转换为32位类型、有符号类型转换为无符号类型、稍微篡改类型直到它们对齐来“帮助”它们。需要遵循某些隐含的强制转换规则，即使这些规则可能与您的直觉不符。因为这是预期的行为，所以编译器在这样做时不需要警告您。

我们使用size_t已经有几十年了。不幸的是，现代代码中仍然充斥着应该使用size_t却使用int或unsigned int的循环，而且错误指定的函数实参类型比比皆是。它工作得很好，直到它不再工作。不要让我开始讲time_t的错误用法。

显式类型转换错误

const int data[512] = {0};
volatile uint32_t* WDT_REG = 0xFFFFFFE0;
/* ... */
byte_sending_function((char *)data, sizeof(data));
handle_watchdog((uint32_t *)WDT_REG);

byte_sending_function的转换应该是(const char *)， handle_watchdog的签名需要接受一个volatile指针。

是的，我知道c++中的static_cast和reinterpret_cast。但是C风格的强制类型转换仍然存在于书本和课堂中，而且它们仍在将其写入新的c++代码中。在我所见过的所有编译器中，抛弃const或volatile都是完全合法的。

谁需要错误处理呢?

#include <stdio.h>
#include <stdlib.h>int main() {
   FILE * fp = fopen("file.txt", "w+");
   fprintf(fp, "This cannot possibly go wrong.\n");
   fclose(fp);
   
   return 0;
}

这个可爱的例子来自谷歌#1的“fopen example”(稍微重新格式化一下)，它并没有费心去检查我们是否真的可以打开文件，编译器也不要求甚至不提醒我们这么做。对我来说工作，不是一个bug，赶快编译，因为我有更多的潜在段错误，我需要添加到这个代码库。砍砍。

(在查看这篇文章时，我意识到fprintf和fclose也可以返回负值来表示失败。我忘记了，因为即使是正确验证fopen句柄的代码，也经常不检查单个fprintf返回值。忽略这个检查不会出现segfault，但是代码也不会知道它是否不能正确地写入文件。)

Buffer overfl$%^&#\b0x9328A7F0Segmentation fault

本段执行了非法操作，必须终止。

如果您认为您看到的是错误的信息，请联系技术支持。

联盟类型（Union types）

union {
  int id;
  void * widget_ptr;
} widget;#ifdef LINUX
widget.id = 42;
#else
widget.widget_ptr = malloc(64);
#endif/* many lines later... */
/* I'm quite certain I stored a pointer in here */
free(widget.widget_ptr);

伙计们，我要把这个按钮和一个小牌子放在这里，上面写着“请勿触摸”。“只要没人滥用它，我们就没事。”

线程安全

我甚至不打算深入可重入函数、副作用、原子性、互斥和信号量、内存屏障等细节。C和c++是为单线程命令式编程而设计的——你给计算机一个按顺序执行的计算列表。如果你想聪明一点，在多线程应用程序中使用它，那么你就有责任熟练使用指针、别名和共享状态，避免在代码中的任何地方犯任何错误。如果它成功了，你将拥有世界上最快的商业应用。如果没有，会有人在你离开之前发现问题吗?据说，天才和疯狂是一枚硬币的两面;让我们来探讨一下这个界限。下面是您的最佳实践指南。瓦尔哈拉殿堂等待。

好吧，我懂了。但是我喜欢C语言，我们不能直接修复C/ c++吗?

大量的工作已经投入到使警告更智能、改进文字、记录最佳实践等方面。c++ 11/14/17中有一些非常有用的新特性:unique_ptr、基于范围的for循环和RAII，它们都可以帮助防止bug(如果你使用它们的话)。有像MISRA这样的标准组织和像CERT这样的安全组织来帮助你发现和修复关键的安全和安全问题，如果你的团队中的每个人都严格遵守这些建议的话。但K&R C的尖锐碎片仍在地板上乱扔，没有什么能阻止你或你旁边的人无视警戒线，绊倒在上面。

尽管在工具和过程上投入了大量的努力，C标准仍然有大量未定义的行为。总之，驱动世界上大多数软件的这两种编程语言都被微妙而又根本地破坏了，因为受过训练的、聪明的专业人员在生产过程中总是犯代价高昂的错误。我们共同努力掩盖这个问题，这证明了仅两位贝尔实验室工程师的惊人技能，他们的语言足够灵活，可以让我们尝试所有这些修复!但我们确实需要解决根本的结构性问题。而且，不幸的是，我们不能在不破坏向后兼容性的情况下修复C语言。

C和c++代码管理你的汽车的油门控制，安全气囊，和防抱死制动系统。它是关键和非关键客机的航空电子软件的基础。它悄无声息地在一堆你不加思索地使用的东西上运行嵌入式操作系统，你所期望的东西是如此简单，它们应该是默认的安全和稳定的。信用卡终端。电力电网系统。电梯。军事硬件。无线路由器。自动取款机。投票机。作为一个以编写嵌入式软件为生的不可靠的人，这让我感到害怕。

总的来说，我们之所以使用这些工具，是因为它们很熟悉，但经验表明，我们无法安全地使用它们。我喜欢C语言，我们非常感谢它的遗产。但我们也有责任用能够帮助我们克服自身缺点的语言来写作。问题不在于我们在道路上安装照明弹来照亮我们的房子，而煤气灯更合适，尽管周围确实有足够的煤气灯。问题是我们根本不应该使用火。我们现在有LED手电筒。是时候停止点蜡烛了。

 

原文：https://medium.com/dwelo-r-d/abusing-fire-for-light-a6e6774289fd

本文：http://jiagoushi.pro/node/1439

讨论：请加入知识星球【全栈和低代码开发】或者微信【it_training】或者QQ群【10777】

亚马逊回声。 FitBit。甚至你的咖啡壶。

虽然你可能会认为“这些事情之一不像其他的东西”，但它们都是物联网（IoT）的例子。

它们都是可以连接到互联网并被其他设备识别并向数据库提供信息的日常物品。物联网描述了Internet V.2，其中数据是由事物创建的。

数字创新专家凯文·阿什顿（Kevin Ashton）被认为是用这个术语来定义物联网的定义：

“如果我们有电脑知道所有事情，就可以从他们所收集到的数据中获取信息，我们将能跟踪和计算一切，大大减少浪费，损失和成本。我们会知道什么时候需要更换，修理或召回，以及他们是新鲜还是过去最好的。“

既然物联网已经使物理世界成为一个庞大的信息系统，物联网将如何影响到2017年的业务？

这只是物联网的开端

虽然有些人会认为IoT以比预期的更低的采用率开始了一个摇滚的开始，但大多数人会同意IoT正在增长，并将在2017年及以后继续增长。到2020年到2020年连接设备的高端预测还有待观察，但我坚信，学习利用物联网创造的数据的企业是未来将会生存和发展的企业。

由于物联网，现在有几种新产品和创新。

更智慧的家园

2016年智能家居技术肯定会有很大的应用;专家认为，亚马逊在2016年假期的销售量比去年同期高出9倍。智能家居技术调查显示，智能家居技术在2017年将变得更加重要。根据智能家居技术调查，智能家居技术调查显示，70％的购买智能家居设备的人认为他们更有可能购买更多。

穿戴技术

2015年销售的可穿戴产品有7810万件，到2020年市场预计将增长到4.11亿。所有可穿戴技术，包括智能手表，健身追踪器，VR耳机等，都能产生大量企业刚刚了解的数据可能性和潜在应用。

智能车

据估计，到2021年，令人惊讶的82％的汽车将连接到互联网。应用程序集成，导航和诊断工具，甚至自驾车将是物联网改变汽车行业的方式。汽车行业正在大力投入决定下一届IofT创新。

改变我们做生意的方式

我们只是抓住了物联网为消费者提供新产品和可能性的方式，但也会影响我们的业务。这里只是几种方法：

1. 库存管理：任何花了工作日或周计数小部件的人都会欣赏物联网对库存管理的美感。智能设备最终将能够自动跟踪广告资源。

2. 消费者需求：消费者将习惯于智能设备，并开始期待他们生活中各方面的“聪明”行为。发明家将有一个实地的日子，提供新的小工具，家具，家电等，以满足这种新的需求，并为企业提供新的收入来源。

3. 较短的购买周期：企业将需要以更短的购买周期和消费者对物联网支持的即时满足度的期望来达成。

4. 从数据中学习：从智能设备生成的数据量可帮助企业了解如何以及创新的最大影响。

5. 远程工作：随着物联网变得更加集成，可以为需要现场完成工作的任务提供更多的远程工作机会。

毫无疑问，物联网刚刚开始。现在开始在其产品，服务和运营中开发或扩展物联网技术的企业是实现竞争优势的企业。

当然，与大多数新创新一样，IoT也有缺点;目前，大多数IoT设备都没有安全保护，使其成为黑客的轻松目标。去年，数百万个物联网设备遭到黑客入侵，被用来占用互联网的一些基础设施。未来，物联网制造商将会更加注重安全性，用户应采取一切预防措施来保护设备。

 

无论您是IoT还是经验丰富的老将，您可能以前听说过“IoT Platform”一词。毕竟，去年有超过300个物联网平台，这个数字继续快速增长（我听说现在有700多个）。物联网平台市场的复合年增长率（CAGR）为33％，预计在2021年将达到16亿美元。

物联网平台是物联网生态系统的关键组成部分，但是我发现，对于许多人来说，目前还不清楚什么是物联网平台或者它们之间的区别。

在这篇文章中，我将为IoT平台提供一个简单的，非技术性的解释。它们是什么，当企业使用它们时，以及在众多选项之间进行选择时的重要考虑。

那么什么是IoT平台呢？

要了解什么是物联网平台，首先您需要了解一个完整的IoT系统的组件。我以前的帖子，“物联网系统如何工作？”是一个很好的学习方式，但我将在这里快速总结。

1. 完整的IoT系统需要硬件，如传感器或设备。这些传感器和设备从环境（例如水分传感器）收集数据或在环境中执行动作（例如浇水作物）。

2. 完整的IoT系统需要连接。硬件需要一种将所有数据传输到云端的方法（例如发送湿度数据）或需要一种从云接收命令的方法（例如，现在对作物播种）。对于一些IoT系统，可以在硬件和连接到云之间的中间步骤，例如网关或路由器。

3. 完整的IoT系统需要软件。该软件托管在云端（什么是云端），并且负责分析从传感器收集的数据并作出决定（例如，从湿度数据知道刚刚下雨，然后告诉灌溉系统今天不打开） 。

4. 最后，完整的IoT系统需要用户界面。为了使所有这些都有用，需要一种方式让用户与IoT系统进行交互（例如，具有显示湿度趋势的仪表板的Web应用程序，并允许用户手动打开或关闭灌溉系统）。

IoT平台是连接IoT系统中的所有内容的支持软件。 IoT平台有助于通信，数据流，设备管理和应用功能。

IoT平台存在于第3部分中，通常是上述内容的第4部分。随着所有不同种类的硬件和不同的连接选项，需要一种使所有工作在一起的方式，这就是IoT平台所做的工作。

IoT平台帮助：

• 连接硬件

• 处理不同的通讯协议

• 为设备和用户提供安全和身份验证

• 收集，可视化和分析数据

• 与其他Web服务集成

您的业务何时应用物联网平台？

由于IoT是一个系统系统，因此在所有相关领域拥有专长的组织很少见。存在物联网平台，可帮助企业克服技术挑战，而无需将其全部归咎于内部。

例如，您的业务可能真的很好的构建硬件，并决定要使您的硬件“聪明”。而不是雇用软件开发人员在内部构建一切的昂贵和耗时的过程，您可以使用IoT平台快速，更经济地开始运行。

但是，有一个权衡。 IoT平台可以节省您的时间，从长远来看，价格可能会更高，这取决于它们的价格。这是因为他们收取使用和/或订阅费用，这些费用可能随着时间的推移而增加。但是，您仍然可以获得显着降低前期成本（无资本支出）的好处。

在前期廉价的IoT平台可能会花费你的时间。这可以回到同样的一点，粗体上面，你花更少的工作，你必须自己做，这需要时间。

Low-power Wide-area Networks: Enabling Geo-IoT

Although the term ‘Internet of Things’ (IoT) has actually been around since the end of the last millennium, the true potential of IoT has only started to unfold beyond the interest of pioneers in the last couple of years. One of the reasons IoT is now booming is the emergence of more low-power wide-area networks (LPWANs) that enable location-aware devices to interconnect in a power-efficient manner. This Technology in Focus article explains the concept of LPWANs and the link to geographic information.

(By Sabine de Milliano, contributing editor, GIM International)

LPWANsare designed to allow wireless communication over a long range at a low data rate. These two distinctive characteristics open up a whole new range of applications, in particular because of the lower power consumption and lower costs that are associated with LPWANs as opposed to traditional machine-to-machine (M2M) communication using SIM cards. For example, installing and maintaining numerous water-quality sensors in a river, canal or other water body becomes a lot more cost efficient if you do not have to replace batteries every few months nor pay for an expensive mobile data subscription for each of your sensors. Provided the hardware is designed efficiently, you could now leave sensors unattended in the field for up to several years, plus the network costs per sensor drop significantly. Additional emerging technologies such as energy harvesting – in which devices collect small amounts of energy in various ways to replenish their power – can even potentially make sensors and devices completely autonomous throughout their entire product lifetime.

Protocols

There are various types of LPWANs, and both the technology and the commercial market are still in development. For the purpose of simplicity, this article will briefly compare the most widely known LPWANs: LoRaWAN, Sigfox, Narrow-Band IoT (NB-IOT) and LTE-M. These LPWANs all differ in their communication implementation, individual power consumption, bandwidth and type of band, geolocation capabilities, type of native security, current coverage for deployment and whether they make use of open standards or proprietary technology. LoRaWAN, for example, is a wideband system that requires a specialised chip developed by Semtech (which implies it is not an open standard), but there are a couple of network suppliers to choose from. The French system Sigfox, which is a type of ultra-narrow band (UNB) network, is considered to be one of the most power-efficient networks currently available but its bandwidth is very limited and more suitable for one-way than two-way communication. And although it uses an open standard – so anyone can potentially develop a device for use with Sigfox – it still requires you to use the Sigfox network. Both NB-IOT and LTE-M differ from LoRaWAN and UNB in that they make use of existing cellular networks. For example, NB-IOT reallocates part of the 4G band for the LPWAN. This means there is no new network infrastructure required, as the technology uses existing cellular network towers.

Competition

Table 1 gives an overview of the relative advantages and disadvantages of the four LPWANs. The question that often arises from such comparisons is: who is going to win the LPWAN battle? Sigfox and LoRaWAN have the time advantage as they are currently more mature than NB-IOT and LTE-M. The latter two, however, will probably become strong competitors (if – arguably – not winners eventually) thanks to their different business model and promising technical characteristics. But the future battle is not just between the four IoT enablers discussed here; there are also various current initiatives to launch an IoT network into space based on small (nano-) satellites that together deliver global coverage for internet access and tracking services. It is just a matter of time before these plans become reality.

Table 1, Some properties of LPWAN technologies that determine their fitness for use for a particular application.

	LoRaWAN	Sigfox	NB-IOT	LTE-M
Power consumption	low	very low	very low	low
Amount of data transfer	low, amount depends on local providers	very low, mainly suitable for one-way communication	low	medium
Native localisation available	yes, differential time of arrival calculated at network	yes, differential time of arrival calculated at network	possible to inherit from existing LTE positioning	possible to inherit from existing LTE positioning
Suitable for time-critical applications	no	yes	yes	yes
Type of band	unlicensed	unlicensed	licensed	licensed
Potential choice of network	multiple network initiatives	requires Sigfox network to be used	delivered by cellular network providers	delivered by cellular network providers
Potential choice of hardware	requires Semtech chip	no restrictions	no restrictions	no restrictions
Current coverage for deployment	initiatives worldwide, but still mainly operational in Europe	parts of Europe, some other countries planned for roll-out	first trials operational	still in development phase

Positioning

One service that is of particular interest to the geomatics industry is the delivery of positioning by LPWAN providers without the need for GNSS. LoRaWAN and Sigfox enable medium-accuracy geolocation of devices through different time of arrival that is carried out by the network itself, which sends back the location information to the device. In this way, the device requires no additional hardware or power to become a smart, location-aware end node. Similarly, NB-IOT and LTE-M can inherit the existing LTE positioning technology to provide native localisation.

Location is key

The market for new IoT applications is expected to become very big. LPWANs enable many new applications with a geographic component. The growing number of devices can either gather large amounts of geographic data, or they can be triggered to perform specific actions based on their location. In both cases geographic data plays a vital role, which opens up a wide range of opportunities for the geomatics industry to enter the world of geo-IoT.

正如我在之前的#askIoT文章中所探讨的那样，几乎每个IoT系统都需要一些方法来将传感器/设备连接到云端，以便数据可以在它们之间来回传递。 IoT网关在使连接成为可能方面至关重要，但是什么是网关？

网关作为传感器/设备和云端之间的桥梁。

许多传感器/设备会与网关“通话”，网关将把所有信息和“谈话”给云（什么是云？）。

但为什么额外的步骤？

现在你知道一个网关是什么，你可能会想知道在传感器/设备和云之间采取额外的步骤有什么好处。结果有几个好处：

• 电池寿命

如果传感器/设备位于远程区域，则可能需要远程连接，例如卫星连接才能与云端通话。如这里所述，较长的范围通常意味着增加的功耗（和成本）;这对于具有有限电池寿命的小型传感器/设备来说可能是一个问题。

如果您正在做Smart Agriculture，您希望您的现场传感器能够持续数年，而不是数月或数周。通过使用安装在外围或谷仓仓顶部附近的高架网关，传感器/设备只需要将数据发送到网关的距离很短，并且网关可以通过单个更高带宽的连接将数据回传到云端。

网关允许传感器/设备在较短距离内进行通信，从而提高电池寿命。

• 不同的协议

完整的IoT应用可能涉及许多不同种类的传感器和设备。再次使用智能农业，您可能需要传感器的温度，湿度和阳光以及自动灌溉和肥料系统等设备。

所有不同的传感器和设备都可以使用不同的传输协议（基本上是传输信息的规则和格式）。协议包括LPWAN，Wi-Fi，蓝牙和Zigbee等等。

网关可以通过不同协议与传感器/设备进行通信，然后将该数据转换为标准协议（如MQTT），以发送到云端。

• 未过滤的数据

有时，传感器/设备可以产生如此多的数据，这是数据压倒在系统上或传输和存储成本极高的情况。通常在这种情况下，只有一小部分数据实际上是有价值的。例如，安全摄像机不需要发送空走廊的视频数据。

网关可以预处理和过滤由传感器/设备生成的数据，以减少传输，处理和存储要求。

• 高延迟

在上周的#askIoT文章中，我解释说，时间对于某些IoT应用来说可能至关重要;传感器/设备无法将数据传输到云端，并在采取行动之前等待获得响应。对于医疗领域的生命或死亡情况或汽车等快速移动的物体，这是真的。

通过处理网关上的数据并在本地发出命令可以避免更高的延迟。然而，IoT应用中的许多传感器/设备太小，电池太低，无法进行处理。

网关可以通过在网关本身而不是在云中执行处理来减少时间关键应用程序的延迟。

• 安全

连接到互联网的每个传感器/设备都容易被黑客入侵。被劫持的传感器/设备是坏的。不只是为业主，而是为所有人。

几周前，名叫未来的恶意软件被用来攻击和控制数以千计的物联网设备。然后，这种“机器人网络”的设备被用来占用互联网的主要部分（更多关于未来）。

网关减少了连接到互联网的传感器/设备的数量，因为传感器/设备仅连接到网关。然而，这使得网关本身成为目标，也是第一道防线。这就是为什么安全需要成为任何网关的优先考虑的原因。

七月份，黑客在每小时70英里的时候关闭一辆汽车。 8月份，研究人员开启了ZigBee网络协议，为从Philips Hue灯泡到Kwikset智能锁的所有工具铺平了道路。今年的DEF CON安全会议由三个全天的物联网（IoT）黑客研讨会和研讨会组成，从不祥之地的“摇篮摇篮：劫持IoT婴儿监视器”开始。

下载报告研究：物联网安全状态

物联网背面有一头牛仔，很容易看出为什么：由于没有中心的物联网标准，没有真正的监督开发，Gartner估计将在今年年底前使用的近50亿智能设备是诱惑的目标是那些想要破坏或更糟糕的人。

IoT标准可以救我们吗？

IoT标准谈话始于2013年初，但到目前为止，可能已经太晚了。技术行业在制定标准时不是闲置的。在标准接近批准之前，太多的技术战争获胜或失败。 Betamax的鬼魂仍然困扰着这个行业。

通常情况下，标准谈话已经开始，各种联盟已经形成，一些党派，更独立。到2014年，这些标准中的少数已经成熟，今天有几个标准甚至在有限的基础上开始认证产品。

也就是说，大家都同意我们距离通用的物联网标准还有很长的路要走，实际上很少有人希望单一的标准将会像Wi-Fi和DVD这样的标准成为主流。其中一部分是物联网本身的挑战。甚至对物联网的内容甚至没有一个共同的定义 - 灯泡标准如何与起搏器标准协调一致？

相关性丢失

围绕标准的其他对话是我们是否需要它们的问题。我们越来越多地发现Wi-Fi，IFTTT，SmartThings和其他旨在将不相容的技术结合在一起的创新，无论他们是否有意合并。除了与诸如蓝牙，ZigBee和Z-Wave之类的一些成熟的通信协议的兼容性之外，许多人正在询问物联网标准是否可能是无关紧要的。

space150首席技术官Marc Jensen和一名严重的物联网骇客，他说：“这里还是野外狂野的西部。 InfoTech Solutions for Business的系统集成商创始人兼首席执行官Matti Kon补充说：“马已经出来之后，我们正试图关闭谷仓的门。”

北卡罗来纳州无线研究中心的总经理拉里·史蒂夫恩（Larry Steffann）是一个区域性的非营利性无线研究小组，对这个问题采取了市场化的做法：“我们鼓励人们继续发展，不要等待任何标准。 “

那么有几个人仍然关心标准 - 主要是那些继续发展的标准。一个关键的事情是，物联网需要大量技术从无线通信到数据安全，以及与其他设备的通信。单一标准不可能涵盖所有这一切，只有单一标准涵盖了笔记本电脑的工作方式。

AT＆T Foundry运营总监Craig Lee全力以赴。 “在物联网标准领域，我们可以考虑四个标准正在运行的层次：第一个是应用层，研究开发IoT应用的协议，正在IETF，OASIS，OMA和W3C等标准体系中开发第二个是服务层开发支持IoT服务的框架。“Lee继续说道。

这些框架正由一个M2M，OIC和AllSeen开发。下一层是网络，它正在查看支持IoT的优化。最后，有访问技术希望优化与IoT服务一起使用的应用程序和框架层，并访问网络特定的优化。这些访问优化正在由3GPP，IEEE 802.11和802.15，Bluetooth SIG，Weightless SIG等开发。

这是很多标准，在这里不可能覆盖所有的标准。考虑到这一点，让我们来看看在这个频谱范围内开发的一些主要标准在2015年中期的位置，以及每个人的预后。

线程组

线程是最小的标准组合之一，但可以说是最有势头的，这得益于IoT（现在由Google母公司由Alphabet拥有）的海报小组Nest的支持。线程是一个雄心勃勃的，以无线为中心的标准，涵盖网络，节能，安全和产品兼容性。此外，每个线程认证的设备都获得IPv6地址，这可以最终缓解IoT设备的网络问题，因为IPv6获得更多的牵引力。

Grid Connect公司的副总裁Adam Connect表示：“线上公司正在为智能传感器提供工业和住宅用途，”Thread现在有了一个规范，并且正在推出2016年发布的产品。线程看起来是一个有希望的新型无线网络标准应该对ZigBee和Z-Wave进行网状网络的改进。“ ZigBee联盟最近与Thread合作，这将为新标准提供更多的可见性。

CipherCloud的云安全和策略副总裁陈曦补充说，线程有很大的潜力。 “线程的基于IP的网状网络协议在业界得到了很好的体现，并且在业界得到广泛应用。网状网络的概念在互连设备环境中运行良好，在这些环境中，没有任何设备成为单点故障。看好这个协议的未来。“

拥有超过80个成员，包括三星和飞利浦，现在已经成为集团的一部分，尽管青年时代，Thread还是标准组织的前瞻性。

AllSeen联盟/ AllJoyn

AllJoyn协议最初由高通公司设计，现在由Linux基金会管理，是成为AllSeen联盟的标准，该联盟是第一个正式启动的重要的IoT标准组织。 AllJoyn是一个开源框架，用于指导IoT设备的连接和服务层操作，以“创建可与其他附近设备，系统和服务直接发现，连接和交互的互操作产品，而不管传输层，设备类型，平台，操作系统或品牌。“具体来说，AllJoyn并不是一个无线电协议，不同于线程，所以这两个可能能够和平共存。

IoT安全设备平台开发商IControl Networks首席技术官Corey Gates指出：

AllJoyn定义了一种安全加入协议，可以实现Wi-Fi网络中的对等设备之间的通信。虽然没有明确要求Wi-Fi，AllJoyn是开发Wi-Fi的。 AllJoyn定义了设备可以实现的服务接口，以实现各种功能。 AllJoyn没有专门定义设备类型，而是设备可以支持或交互的服务。几家公司已经建立了概念证明，AllJoyn兼容设备，但很少有上市。目前，大部分重点是音频流和控制以及家庭路由服务。

正义指出，尽管今天，AllSeen联盟拥有170多个成员，其中包括微软，索尼和Lowe，“在产品出货和宣传AllJoyn兼容性方面，市场上看不到太多。”也就是说，该集团继续快速增长，定期拾起蓝筹股，而且在今年的消费电子展（CES）上确实有一席之地。

开放互连联盟/ IoTivity

英特尔在线上同时成立了开放互连联盟，但吸引力和兴趣并没有像Nest支持的组织那样高。伊斯兰会议组织在很大程度上被视为对AllSeen巨人的回应。更具体地说，它被视为对高通的直接攻击。今年的大部分标准对话涉及到这两个知识产权集团之间的冲突，最终导致AllSeen联盟承诺，任何一个成员都不会起诉任何使用AllSeen标志进行专利侵权的人。

今年早些时候，OIC发布了一个名为IoTivity的规范，即设备到设备通信的另一个框架，以及AllJoyn的直接竞争对手，尽管IoTivity设备尚未进入市场。 （IoTivity博客仍然只有一个帖子，日期为2014年12月）

也就是说，AllSeen没有太多的开始，伊斯兰会议组织继续成为会员。据我所知，该集团目前拥有近100名成员，其中包括与DLNA和UPnP论坛的重要联络协议。

工业互联网联盟

顾名思义，工业互联网联盟（IIC）成立于2014年3月，正在制定与物联网的工业应用相关的指导原则。主要由GE，IBM，思科，AT＆T以及英特尔等大型企业支持。 （这五家公司在IIC指导委员会有常任理事国。）

IIC表示，它不是开发自己的标准，而是正在通过识别，组装和推广最佳实践，汇集加速工业互联网发展所必需的组织和技术。“ Gartner质疑了联盟的相关性，但IIC在今年夏天早些时候发布了其工业互联网参考架构。虽然不是标准，但是该文件“概述了工业互联网系统的关键特征，在部署工业互联网解决方案之前必须考虑的各种观点，以及对工业互联网的关键问题的分析，包括安全和隐私，互操作性和连接性， “根据美国商业资讯。行业回应尚未确定。

ITU-T SG20

国际电信联盟成立于2015年6月，其新兴标准不仅涵盖了物联网，还包括“聪明的城市和社区（SC＆C）”。 SG20标准“负责国际标准，以实现物联网技术的协调发展，包括机对机通信和普遍存在的传感器网络。

ITU-T标准的一个问题是美国没有任何重大的参与，但是Kon是一个粉丝，他说：“我认为SG20将会出现，他们拥有最大的权力和最大的支持[在全球范围内]，但是当世界已经实施物联网时，他们仍处于研究阶段。“

IEEE P2413

自然而然，IEEE正在采取行动，而有名的组织则指出：“在IEEE中，有适用于IoT的350多种IEEE标准，其中40项正在修订，以更好地支持IoT。此外，还有更多的在不同的发展阶段超过110个新的IoT相关的IEEE标准，IEEE也赞助了10个或更多不同的IoT倡导和支持组织。

这是很多的标准化，但它是IEEE项目P2413作为所有这一切的伞。再次，积极的目标是建立一个“涵盖基础架构构建块的定义及其集成到多层系统的能力”的参考架构。

IoT服务公司Greenwave Systems的首席科学家和技术传播者Jim Hunter指出，与IEEE一样，我们看到了一个趋势的开始，这种趋势往往会影响标准制定：伙伴关系和协作。 “某些标准组织正在开始合作，”他表示，“将出现一个更广泛扩散的标准，最引人注目的是，IEEE IoT Architecture小组为定义IoT的架构标准所做的巨大工作范围，P2413正在建立联络IIC，2MM以及其他几个IoT工作组，这里的工作很早，主要集中在研究和数据收集阶段。

Apple HomeKit

苹果公司的折扣将是愚蠢的，苹果公司的HomeKit是“在用户家庭中与连接配件进行通信和控制的框架”。当然，这并不像苹果专有的做事方式那么标准。应用开发商和硬件制造商可以选择加入俱乐部或留在围墙花园外面。

不过，Hunter说“HomeKit”并没有像预期的那样起飞，其中一个重要原因似乎是苹果公司坚持采用尖端的3072位加密密钥和由Wi-Fi和蓝牙设备使用的Apple认证的芯片。现有设备必须决定是否重新设计现有的产品线，以便启用HomeKit支持。“

另一方面：HomeKit设备实际上是运输，没有什么比货架上的实际产品更符合标准。

摇摆不可避免

最终，这些标准中的一个以上可能会减少，但是他们是否在市场上有很大的不同之处还有待观察：“所有这些标准都处于通量状态，”首席技术官Dave Evans说，的Stringify。 “现在说哪些都会被留下来还为时过早，其中一些甚至在12至18个月前都没有存在，毫无疑问，在接下来的几年里，我们会看到更多的东西。

物联网（IoT）是一个相互关联的计算设备，机械和数字机器，物体，动物或人类的系统，它们具有唯一的标识符，并且能够通过网络传输数据，而不需要人与人或人 电脑互动“。

- 物联网议程上的“物联网”。

仍然不知道物联网系统如何运作？

我不怪你虽然快速的Google搜索将会提供大量的文章和帖子，解释物联网是什么以及其许多潜在的好处，但是并没有明确物联网系统如何实际运作。

作为Leverege的业务发展总监，我经常发现自己澄清那些非技术性的人。所以，作为一个非技术性的人，我自己（在布朗，我是哲学专业），这里是一个以简单的非技术术语解释的物联网。

物联网解释

完整的IoT系统集成了四个不同的组件：传感器/设备，连接，数据处理和用户界面。下面我将简要介绍一下每个组件及其功能。

1）传感器/设备

首先，传感器或设备从他们的环境中收集数据。这可能像温度读数一样简单，或者像完整的视频馈送一样复杂。

我使用“传感器/设备”，因为可以将多个传感器捆绑在一起，或者传感器可以作为不仅仅是检测事物的设备的一部分。例如，您的手机是具有多个传感器（相机，加速度计，GPS等）的设备，但您的手机不仅仅是传感器。

然而，无论是独立的传感器还是完整的设备，在第一步中，数据是从环境中收集的。

2）连接

接下来，这些数据被发送到云端（什么是云端），但它需要一种方式才能到达！

传感器/设备可以通过多种方式连接到云端，包括：蜂窝，卫星，WiFi，蓝牙，低功耗广域网（LPWAN），或通过以太网直接连接到互联网。

每个选项在功耗，范围和带宽之间进行权衡（这里是一个简单的解释）。选择哪个连接选项最好归结于特定的IoT应用程序，但它们都完成了相同的任务：将数据传输到云端。

3）数据处理

一旦数据进入云端，软件就可以进行某种处理。

这可能非常简单，例如检查温度读数是否在可接受范围内。或者也可能非常复杂，例如使用视频上的计算机视觉来识别物体（如您家中的入侵者）。

但是，当温度过高或者家中是否有入侵者会发生什么？这就是用户进来的地方。

4）用户界面

接下来，这些信息以某种方式对终端用户有用。这可能是通过对用户的警报（电子邮件，文本，通知等）。例如，当公司的冷库中的温度过高时，文字提醒。

此外，用户可能有一个允许他们主动登录系统的界面。例如，用户可能想要通过电话应用程序或网络浏览器检查他们家中的视频馈送。

但是，并不总是单向街道。根据IoT应用，用户也可以执行动作并影响系统。例如，用户可以通过手机上的应用程序远程调节冷库中的温度。

并且自动执行一些操作。而不是等待您调整温度，系统可以通过预定义的规则自动进行。而不是只是打电话给你提醒你一个入侵者，物联网系统也可以自动通知有关当局。

概述 - 物联网系统如何运作

IoT系统由通过某种连接与云“通话”的传感器/设备组成。一旦数据进入云端，软件就会处理它，然后可能决定执行一个动作，例如发送警报或自动调整传感器/设备，而不需要用户。

但是如果需要用户输入，或者用户只需要在系统上登录，用户界面就可以这样做。然后，用户进行的任何调整或操作都将以相反的方向通过系统发送：从用户界面到云端，并返回到传感器/设备进行某种更改。

真正的物联网（IoT）要求“事物”能够使用互联网协议。互联网上一直存在着各种各样的“事情”，数据中心和家庭的通用计算机通常可以使用互联网协议，因为它们已经被定义了。然而，将互联网扩展到通常需要优化版本或特殊使用这些协议的更受约束的设备具有相当大的价值。

背景

在过去十年中，已经开展了各种IETF活动，以便广泛的事情使用互操作技术进行通信，从相当小的微控制器传感器到数据中心的大型计算机。

当我们在2010年IETF杂志上写到关于IoT的文章时，有三个IETF工作组（WG）专注于约束设备和网络的IoT：6LoWPAN，它定义适合于受限无线电链路的IPv6适配层和报头压缩; ROLL专注于约束节点网络的路由协议;和CoRE，旨在将Web架构扩展到大多数受限网络和嵌入式设备。关于物联网的活动自2010年以来有所增加，今天我们有七个工作组积极研究物联网的各个方面（另外两个已经完成），以及专注于开放式物流研究问题的互联网研究任务组（IRTF）研究小组。

IETF IoT活动

第一个IETF IoT工作组，IPv6 over低功耗WPAN（6LoWPAN），于2005年3月被授权。它定义了将IPv6适配到使用非常小的数据包大小的IEEE 802.15.4（WPAN）网络的方法，通过头压缩和优化为邻居发现。 6LoWPAN工作组于2014年完成，6Lo工作组取而代之的是将相似的适应机制应用于更广泛的无线电技术，包括“蓝牙低能耗”（RFC 7668），ITU-T G.9959（Z-Wave ，RFC 7428）和数字增强无绳电信（DECT）超低能耗（ULE）无绳电话标准以及低成本有线网络技术主从通/令牌传递（MS / TP），广泛应用于RS- 485楼宇自动化。

低功耗和有损网络路由（ROLL）WG为RPL协议“低功耗和有损网络的IPv6路由协议”（RFC 6550）制定了一系列相关扩展，包括各种路由度量，目标函数，和组播。 ROLL的另一个输出是一些需求文件和适用性声明，术语文档和安全威胁分析。

受约束的RESTful环境（CoRE）WG仍然是最活跃的IoT组之一。其主要产品围绕“约束应用协议”（CoAP，RFC 7252），基于UDP的基于UDP的模拟。 CoAP扩展功能可以实现组通信（RFC 7390）和低复杂度服务器推送资源观察（RFC 7641）。这是基于适用于约束设备（RFC 6690）的weblink格式的发现和自我描述机制的补充。当前的工作组活动侧重于扩展，可以传输大量资源，使用资源目录来协调发现，可重用的接口描述以及通过TCP和TLS传输CoAP。 CoRE工作组正在重新考虑，包括RESTCONF风格的管理职能和通过CoAP发布订阅风格的沟通。 CoRE还在研究一种表示传感器测量的数据格式，这将受益于“简明二进制对象表示”（CBOR）（RFC 7049），这是针对二进制数据和低资源实现进行优化的JSON模拟器。

自2010年以来，很明显，物联网在没有安全保障的情况下不会奏效。因此，大多数新的物联网工作组已在安全区域中添加。受约束环境（DICE）工作组（DICE）工作组（已完成）的DTLS生成了适用于受限制的物联网设备的TLS / DTLS配置文件。约束环境的认证和授权（ACE）WG正在开发用于访问受限环境中服务器上托管的资源的身份验证授权机制，并且最近完成了一个综合用例文档（RFC 7744）。这项工作得到了最近授权的COSE工作组的支持，该工作组正在为JOSE工作组开发的JSON对象签名和加密方法构建简化的CBOR模拟。

作为一项特别的开发，超过了6Lo的工作，6TiSCH WG（IPv6 over TSCH模式的IEEE 802.15.4e）在2014年被授权，以使IPv6能够实现最近添加到IEEE的时隙信道跳跃（TSCH）模式802.15.4网络。这项工作旨在利用TSCH的确定性，实时导向特征，并包括架构，信息模型和配置方面。 6TiSCH概述和问题陈述文件（RFC 7554）于2015年发布;一个最小配置接口的规范是下一行。

除了由IETF工作组开发的新协议和其他机制之外，受限环境的互联网协议常常受益于有效实施技术和其他考虑的其他指导。轻量级实施指导（LWIG）工作组正在开展此类文件，包括CoAP和IKEv2协议，非对称加密技术和蜂窝网络中的CoAP。 LWIG工作组发布了RFC 7228，它定义了受限节点网络的常用术语。

除IETF专门关注物联网方案之外，整个Web协议栈正在快速发展，其他IETF工作组开发的许多新技术也将最终也被用于物联网。由于具有更紧凑的线格式和简化的处理规则，HTTPbis WG最近确定了HTTP / 2协议的规范，该规范比早期版本的HTTP更适合于IoT场景。 TLS工作组正在定义TLS版本1.3，包括DTLS 1.3，可以更有效地建立安全的传输会话，因此更适合于物联网。 Homenet工作组正在致力于在家庭及其他地方自动配置IPv6网络。与IETF的标准化工作相似，IRTF的两个研究小组特别感兴趣：ICNRG（信息中心网络），探讨其技术在物联网场景中的适用性，以及进行先进加密基础的CFRG（Crypto Forum），如新椭圆曲线加密（ECC）曲线将更适合于IoT用例。最后，互联网架构委员会（IAB）正在组织多个相关研讨会（例如关于安全性，架构和语义互操作性），并发布了诸如“智能对象网络中的架构注意事项”（RFC 7452）等信息文件。

虽然以物联网为导向的IETF工作组已经产生了关于物联网成熟标准的第一波浪潮，但是基于这些标准的使用，正在出现新的研究问题。 IRTF Thing-to-Thing研究组（T2TRG）于2015年被授权，以调查物联网的开放性研究问题，重点关注在IETF展示标准化潜力的问题。正在探讨的主题包括受限节点网络的管理和运行，安全和生命周期管理，在物联网场景中使用REST范式的方法以及语义互操作性。对于在物联网地区活跃的其他团体的追随和贡献也有很大的兴趣。例如，W3C Web of Things（WoT）兴趣小组最近开始了活动，两个小组一直在共同探讨物联网和Web技术的未来。

结论

IETF已经有十年的历史，指定和记录关键的物联网标准和指导，今天在物联网方面比以往任何时候都有更多的活动。从事物联网的其他组织和联盟已经采用互联网协议栈作为其解决方案的基础。 IP，特别是IPv6是网络的明显选择，但IETF IoT堆栈的其余部分，包括CoAP和DTLS也被广泛使用。今天在RFC中发布的基础IETF IoT协议栈是成熟的，适合部署。标准化的其他需求正在出现，IETF和IRTF的活跃团体正在努力确保其被识别和解决。

物联网设备和应用程序涉及协议的概述。 帮助澄清IoT层技术栈和头对头比较。

物联网涵盖了广泛的行业和用例，从单一受限制的设备扩展到大量跨平台部署嵌入式技术和实时连接的云系统。

将它们捆绑在一起是许多传统和新兴的通信协议，允许设备和服务器以新的，更互联的方式相互通信。

同时，数十个联盟和联盟正在形成，希望能够统一断层和有机的物联网景观。

以下频道指南：

提供有助于IoT设备，应用程序和应用程序的热门协议和标准的概述列表

深入了解特定层次或行业特定协议

列出流行协议的头对头比较（即：mqtt vs xmpp）

协议

我们已经将协议分解成以下层，以提供一定程度的组织，而不是试图将所有的IoT协议都适合现有的体系结构模型（如OSI模型）

基础设施（例如：6LowPAN，IPv4 / IPv6，RPL）

识别（例如：EPC，uCode，IPv6，URI）

通讯/交通（例如：Wifi，蓝牙，LPWAN）

发现（例如：Physical Web，mDNS，DNS-SD）

数据协议（例如：MQTT，CoAP，AMQP，Websocket，Node）

设备管理（例如：TR-069，OMA-DM）

语义（例如：JSON-LD，Web Thing模型）

多层框架（例如：Alljoyn，IoTivity，Weave，Homekit）

安全

行业垂直（连接家庭，工业等）

基础设施

IPv6- “IPv6，是用于分组交换网络互联的互联网层协议，并提供跨多个IP网络的端到端数据报传输。

6LoWPAN - “6LoWPAN是IPv6低功耗无线个人区域网络的首字母缩略词，它是适用于IPv6 over IEEE802.15.4链路的适配层，该协议仅在2.4 GHz频率范围内运行，传输速率为250 kbps。

UDP（用户数据报协议） - 基于互联网协议（IP）的客户端/服务器网络应用程序的简单OSI传输层协议。 UDP是TCP的主要替代品，并且是1980年引入的最早的网络协议之一。UDP经常用于专门用于实时性能的应用中。

- QUIC（快速UDP Internet连接，发音为quick）支持通过用户数据报协议（UDP）的两个端点之间的一组多路复用连接，旨在提供与TLS / SSL相当的安全保护以及减少的连接和传输延迟，以及带宽估计在每个方向避免拥塞。

- Aeron - 高效可靠的UDP单播，UDP组播和IPC消息传输。

uIP - uIP是一种可用于微型8位和16位微控制器的开源TCP / IP协议栈。它最初由瑞典计算机科学研究所“网络嵌入式系统”组织的Adam Dunkels开发，根据BSD样式许可证许可，并由广泛的开发人员进一步开发。

DTLS（数据报传输层） - “DTLS协议为数据报协议提供通信隐私协议允许客户端/服务器应用程序以防止窃听，篡改或消息伪造的方式进行通信，DTLS协议基于传输层安全（TLS）协议，并提供等效的安全保证。“

ROLL / RPL（低功耗/有损网络的IPv6路由）

NanoIP

“NanoIP代表了”纳米互联网协议“，这个概念是为嵌入式和传感器设备提供类似互联网的服务，而无需TCP / IP的开销。NanoIP的设计是以最少的开销，无线网络和本地铭记在心“。

以内容为中心的网络（CCN） - 技术概述

“下一代网络架构解决了内容分发可扩展性，移动性和安全性方面的挑战。

CCN直接在网络的数据包层级路由和传递命名的内容，从而在内存中自动进行应用中立的缓存，无论它位于网络中。结果？无论何时何地需要，内容的高效有效的传递。由于架构可以将这些缓存效应作为分组传送的自动副作用，因此可以使用内存，而无需构建昂贵的应用程序级缓存服务。

时间同步网格协议（TSMP）

一种用于自组织网络的通信协议，称为无线设备。 TSMP设备保持彼此同步并在时隙中进行通信，与其他TDM（时分复用）系统类似。

发现

mDNS（组播域名系统） - 将主机名解析为不包含本地名称服务器的小型网络内的IP地址。

物理Web - 物理Web可以让您看到一个使用蓝牙低能耗（BLE）信标在您周围环境中的对象广播的URL列表。

HyperCat -一种开放，轻量级的基于JSON的超媒体目录格式，用于显示URI的集合。

UPnP（通用即插即用） - 现在由Open Connectivity Foundation管理的是一组网络协议，允许网络设备无缝地发现对方在网络上的存在，并建立用于数据共享，通信和娱乐的功能网络服务。

数据协议

MQTT（消息队列遥测传输）

“MQTT协议以非常轻便的方式实现发布/订阅消息传递模型，对于需要较小代码占用空间和/或网络带宽非常重要的远程位置的连接很有用。

- 其他资源

MQTT-SN（用于传感器网络的MQTT） - 专为机器到机器和移动应用设计的开放轻量级的发布/订阅协议

-Mosquitto：一个开源MQTT v3.1代理

- IBM MessageSight

CoAP（约束应用协议）

CoAP是一种应用层协议，旨在用于资源受限的互联网设备，如WSN节点，CoAP旨在轻松转换为HTTP，以简化与Web的集成，同时满足诸如组播支持等特殊要求低开销和简单性CoRE组为CoAP提出了以下功能：RESTful协议设计，最小化使用HTTP映射的复杂性，低标头开销和解析复杂性，URI和内容类型支持，支持发现由已知的CoAP服务。简单的资源订阅以及结果推送通知，基于最大时间的简单缓存。“

- 其他资源

- SMCP- 适用于嵌入式环境的基于C的CoAP堆栈。功能包括：支持draft-ietf-core-coap-13，完全异步I / O，支持BSD套接字和UIP。

STOMP - 简单文本定向消息协议

XMPP（可扩展消息和存在协议）

“用于实时通信的开放技术，其功能包括即时消息，存在，多方聊天，语音和视频通话，协作，轻量级中间件，内容联合以及XML数据的广义路由等广泛应用。

- 其他资源

- XMPP-IoT

“在XMPP的同一个庄园里，默默地创造了人与人之间的通信互操作性，我们的目标是使通信机对人和机器进行机器互操作。

Mihini / M3DA

“Mihini代理是一个软件组件，作为M2M服务器和在嵌入式网关上运行的应用程序之间的中介者。M3DA是针对二进制M2M数据传输进行优化的协议，它在Mihini项目中可用于手段的设备管理，通过简化设备数据模型的操作和同步，以及通过允许用户应用程序与M2M服务器来回交换数据/命令的手段来进行资产管理，以优化带宽使用的方式“

AMQP（高级消息队列协议）

“面向消息的中间件的开放标准应用层协议AMQP的定义特征是消息导向，排队，路由（包括点对点和发布和订阅），可靠性和安全性。

- 其他资源

DDS（实时系统数据分发服务）

“第一个开放的国际中间件标准直接针对实时和嵌入式系统的发布订阅通信。

JMS（Java消息服务） - 一种面向Java消息的中间件（MOM）API，用于在两个或多个客户端之间发送消息。

LLAP（轻量级本地自动化协议）

“LLAP是一个简单的短消息，它使用正常文本在智能对象之间发送，它不像TCP / IP，蓝牙，zigbee，6lowpan，WiFi等，它们在低级别实现”如何“移动数据，这意味着LLAP可以运行在任何通信媒介上，LLAP的三个优点是，它将在任何现在，任何未来的任何事情上运行，人类很容易理解。

LWM2M（轻量级M2M）

“轻量级M2M（LWM2M）是开放移动联盟的系统标准，包括DTLS，CoAP，Block，Observe，SenML和资源目录，并将其编入设备 - 服务器界面以及对象结构。

SSI（简单传感器接口）

“设计用于计算机或用户终端与智能传感器之间数据传输的简单通信协议”

反应流

“用于JVM上非阻塞背压的异步流处理标准”。

ONS 2.0

REST（表示状态转移） - RESTful HTTP

- 物联网上下文中的附加资源

HTTP / 2- 通过引入头字段压缩并允许在同一连接上进行多个并发交换，可以更有效地利用网络资源和减少对延迟的感知。

SOAP（简单对象访问协议），JSON / XML，WebHooks，Jelastic，MongoDB

Websocket

WebSocket规范 - 作为HTML5计划的一部分开发 - 引入了WebSocket JavaScript接口，该界面定义了一个全双工单一套接字连接，客户端和服务器之间可以发送消息。 WebSocket标准简化了双向Web通信和连接管理的复杂性。

JavaScript / Node.jsIoT项目

可以在这里找到一个名为Contit，Riot OS等的IoT软件项目列表。

通讯/传输层

以太网

WirelessHart

“WirelessHART技术为各种过程测量，控制和资产管理应用提供了强大的无线协议。”

DigiMesh

“DigiMesh是一种用于无线端点连接解决方案的专有点对点网络拓扑。

ISA100.11a

“ISA100.11a是由国际自动化学会（ISA）开发的无线网络技术标准，官方描述为”工业自动化无线系统：过程控制及相关应用“

IEEE 802.15.4

IEEE 802.15.4是一种标准，用于指定低速率无线个域网（LR-WPAN）的物理层和媒体访问控制。它由IEEE 802.15工作组维护。它是ZigBee，ISA100.11a，WirelessHART和MiWi规范的基础，每个规范通过开发未在IEEE 802.15.4中定义的上层进一步扩展标准。或者，它可以与6LoWPAN和标准互联网协议一起使用来构建无线嵌入式互联网。

NFC

基于标准ISO / IEC 18092：2004，使用中心频率为13.56 MHz的电感耦合器件。与无线传感器网络相比，数据速率高达424 kbps，范围短于几米。

蚂蚁

ANT是一种专有的无线传感器网络技术，具有无线通信协议栈，使得能够在2.4 GHz工业，科学和医疗分配RF频谱（“ISM频带”）中运行的半导体无线电通过建立共存的标准规则进行通信，数据表示，信令，认证和错误检测。

蓝牙

蓝牙工作在2.4 GHz ISM频段，并使用跳频。数据速率高达3 Mbps，最大范围为100m。可以使用蓝牙的每个应用程序类型都有自己的配置文件。

Eddystone - 定义接近信标消息的蓝牙低功耗（BLE）消息格式的协议规范。

ZigBee

ZigBee协议使用802.15.4标准，并在2.4 GHz频率范围内工作，速度为250 kbps。网络中的最大节点数为1024，范围可达200米。 ZigBee可以使用128位AES加密。

EnOcean

EnOcean是一种能量收集无线技术，其工作频率为欧洲868 MHz，北美为315 MHz。发射范围在建筑物中可达30米，室外可达300米。

无线上网

WiMax

WiMax基于标准的IEEE 802.16，适用于无线城域网。固定电台的范围是不同的，在那里它可以达到50公里，移动设备有5到15公里。 WiMAx以2.5 GHz至5.8 GHz的频率运行，传输速率为40 Mbps。

LPWAN

无重量

无重量是一种专有的开放式无线技术标准，用于在基站和数千台机器之间交换数据（使用空闲电视传输通道中的波长无线电传输），具有高度的安全性。

NB-IoT（窄带IoT）由3GPP标准体系标准化的技术

LTE-MTC（LTE机器类型通信） - 基于标准的技术系列支持适用于物联网的几种技术类别，如Cat-1和CatM1。

EC-GSM-IoT（扩展覆盖 - GSM-IoT） - 为LPWA（低功率广域）IoT应用实现现有蜂窝网络的新功能。 EC-GSM-IoT可以通过部署在非常大的GSM足迹上的新软件来激活，从而为服务IoT设备增加更多的覆盖范围。

LoRaWAN - 用于无线电池操作的网络协议区域，国家或全球网络中的任务。

RPMA（随机相位多址）采用具有多路访问的直接序列扩频（DSSS）技术的通信系统。

手机：

GPRS / 2G / 3G / 4G蜂窝

- 在这里查看有关物联网通信和技术的更完整的概述。

语义

IOTDB

“用于描述物联网的JSON /链接数据标准”

SensorML

“SensorML为描述传感器和测量过程提供了标准模型和XML编码。”

语义传感器网络本体 - W3C

“这个本体论描述了传感器和观察结果以及相关的概念，它并没有描述域名概念，时间，位置等，这些概念是通过OWL导入从其他本体中被包含的。”

Wolfram语言 - 连接的设备 - “每个设备的符号表示，然后有一组标准的Wolfram语言功能，如DeviceRead，DeviceExecute，DeviceReadBuffer和DeviceReadTimeSeries，执行与设备相关的操作。

RAML（RESTful API建模语言） - 可以轻松管理从设计到共享的整个API生命周期。简明扼要 - 您只需编写您需要定义的内容，并可重复使用。

SENML（传感器标记语言的介质类型）- 简单的传感器，如温度传感器，可以在诸如HTTP或CoAP之类的协议中使用此介质类型来传输传感器的测量值或进行配置。

LsDL（Lemonbeat智能设备语言）- 面向服务的设备的基于XML的设备语言

多层框架

Alljoyn - 一个开放源码的软件框架，可让设备和应用程序轻松发现和沟通。

IoTivity是由Linux基金会托管的开放源码项目，由伊斯兰会议组织赞助。

IEEE P2413 - 物联网建筑框架标准（IoT）

线程 - 基于开放标准和IPv6技术，以6LoWPAN为基础。

IPSO应用程序框架（PDF）

“这个设计定义了一组REST接口，可以由智能对象使用它来表示其可用资源，与其他智能对象和后端服务交互。该框架旨在与现有的Web配置文件（包括SEP2和oBIX）相辅相成。

OMA LightweightM2M v1.0

“LightweightM2M的动机是开发一种快速可部署的客户端 - 服务器规范来提供机器到机器服务。

LightweightM2M主要是一种设备管理协议，但它应该被设计为能够扩展以满足应用程序的要求。轻量级M2M不限于设备管理，应该能够传输服务/应用数据。“

编织 - 用于物联网设备的通信平台，可实现设备设置，手机到设备到云的通信以及来自移动设备和网络的用户交互。

Telehash- JSON + UDP + DHT =自由

一种安全的线路协议，为应用和设备提供分散式覆盖网络

安全

开放信任协议（OTrP） - 安装，更新和删除应用程序以及管理受信任执行环境（TEE）中的安全配置的协议。

X.509 - 用于管理数字证书和公钥加密的公钥基础设施（PKI）标准。用于保护网络和电子邮件通信的传输层安全协议的关键部分。

垂直具体

IEEE 1451：

IEEE 1451是智能传感器接口标准系列，描述了一组用于将传感器（传感器或执行器）连接到微处理器，仪表系统和控制/现场网络的开放，通用，独立于网络的通信接口。

IEEE 1888.3-2013- “无线普及绿色社区控制网络安全标准”

IEEE 1905.1-2013 - “IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies”

IEEE 802.16p-2012 - “IEEE宽带无线接入系统空中接口标准”

IEEE 1377-2012 - “IEEE工业计量通信协议应用层标准”

IEEE P1828 - “虚拟组件系统标准”

IEEE P1856“电子系统预测与健康管理标准框架”

架构和图形

Credit: Simon Ford - Director of IoT Platforms ARM

Graphic via Ronak Sutaria and Raghunath Govindachari from Mindtree Labs in "Making sense of interoperability:Protocols and Standardization initiatives in IOT"

IoT Communication stack from IoT-A Initiative

"The communication model aims at defining the main communication paradigms for connecting entities, as defined in the domain model. We provide a reference communication stack, together with insight about the main interactions among the actors in the domain model. We developed a communication stack similar to the ISO OSI 7-layer model for networks, mapping the needed features of the domain model unto communication paradigms. We also describe how communication schemes can be applied to different types of networks in IoT."

David E Culler Open Standards Reference Model

Above Graphic: David E. Culler - The Internet of Every Thing - steps toward sustainability CWSN Keynote, Sept. 26, 2011 (Download PPT)

Graphic: Sensinode: - Zach Shelby: Is the Internet Protocol enough?

Graphic: EU Butler Project - Communication Issues

联盟和组织

组织机构：

ETSI（欧洲电信标准协会）

- 连接事物群集

IETF（互联网工程任务组）

- CoRE工作组（约束RESTful环境）

- 6lowpan工作组（IPv6 over Low Power WPAN）

- ROLL工作组（低功耗和有损网络）

IEEE（电气与电子工程师协会）

- IoT“创新空间”

OMG（对象管理组）

- 数据分发服务门户

OASIS（结构性信息提升标准组织）

- MQTT技术委员会

OGC（开放地理空间联盟）

- IoT标准工作组的传感器Web

IoT-A

“针对物联网的欧洲灯塔综合项目，提出了建立一个建筑参考模型以及初始的关键构件块的定义。”

OneM2M

“oneM2M的目标和目的是开发技术规范，解决需要一个可以容易地嵌入到各种硬件和软件中的普通M2M服务层，并依靠将现场无数设备与全球M2M应用服务器连接“。

OSIOT

“一个单一的重点是为新兴物联网开发和推广免版税，开源标准的组织。”

IoT-GSI（物联网全球标准倡议）

ISA国际自动化学会

W3C

- 语义传感器网络本体论

- 物联网社区小组

EPC全球

IEC（国际电工委员会）和ISO（国际标准化组织）通过JTC（联合技术委员会）。委员会页

RRG（路由研究组）

HIPRG（主机身份协议研究组）

Eclipse Paho项目

“Paho项目的范围是提供开源和标准消息传递协议的开源实现，支持目前和新兴的M2M与企业中间件和应用程序集成的需求，包括客户端实现，以及相应的服务器支持由社区决定。“

OpenWSN

“作为使用各种硬件和软件平台的基于物联网标准的协议栈的开源实现的存储库。

CASAGRAS

“我们是代表欧洲，美国，中国，日本和韩国的重要的国际合作伙伴，他们加入了欧盟资助的第七个框架计划，该计划将着眼于RFID的全球标准，监管和其他问题及其在实现”物联网“。

联盟

AllSeen联盟

“AllSeen联盟是一个非营利组织，致力于通过一个开放的，通用的发展框架，支持和驱动广泛采用的产品，系统和服务，支持全球互联网，由充满活力的生态系统和蓬勃发展的技术社区支持，

IPSO

“该联盟是一个全球性的非营利组织，为各种社区服务，旨在通过为公众提供协调一致的营销努力，建立互联网协议作为智能对象连接的网络。”

Wi-SUN联盟

Wi-SUN联盟旨在“通过推动基于IEEE 802.15.4g标准的全球区域市场互操作性来推进无缝连接”。

OMA（开放移动联盟）

“OMA是开发市场驱动，互操作的移动服务推动者的领先行业论坛”

- OMA LightweightM2M v1.0

工业互联网联盟

“成立于2014年，进一步开发，采用和广泛使用互连机器，智能分析和工作人员”

 

本文：https://pub.intelligentx.net/overview-protocols-involved-iot-devices-and-applications

讨论：请加入知识星球或者小红圈【首席架构师圈】

此页尝试记录各种MQTT服务器(代理)支持的特性。这是特定于他们的MQTT支持的。这些服务器中有许多具有比MQTT更广泛的功能。

能力

Server	QoS 0	QoS 1	QoS 2	auth	Bridge	$SYS	SSL	Dynamic topics	cluster	websockets	plugin system	Mqtt 5 support	Active development
Aedes	✔	✔	✔	Username/ Password	rm	✔	✔	✔	✔	✔	✔	✘	✔
AWS IoT Services	✔	✔	✔	Client certificates	?	✘	✔	§	✔	✔	✘	✘	✔
Apache ActiveMQ Artemis	✔	✔	✔	JAAS	✘	✘	✔	✔	✔	✔	✔	✘	✔
BevywiseIoT Platform	✔	✔	✔	Key based	✔	✔	✔	✔	✔	✔	rm	✘	✔
ClearBlade	✔	✔	✔	OAuth based User/Pass & Per-channel authorization	?	✔	✔	✔	✔	✔	?	✘	✔
ejabberd	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔
emitter	✔	✘	✘	Per-channel authorization	✘	✘	✔	✔	✔	✔	✘	✘	✔
EMQ X	✔	✔	✔	Username /Password, JWT, LDAP, ClientID, ...	✔	✔	✔	✔	✔	✔	✔	✔	✔
flespi	✔	✔	✔	✔	✘	✘	✔	✔	✔	✔	✘	✘	✔
GnatMQ / M2MQTT	✔	✔	✔	Username Password	✘	✘	✔	✔	✘	✘	✘	✘	✔
HBMQTT	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✘	✔	✔	✘	✔
HiveMQ	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✔	✔
IBM IoT MessageSight	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✘	✔
IBM Watson IoT Platform	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✔
IBM WebSphere MQ Middleware	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✔	✔	✘	✘	✔
Jmqtt	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✘	✔	✔	✘	✔
JoramMQ	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✘
Mongoose	✔	✔	✔	✔	✔	✘	✔	✔	✘	✔	✔	✘	✔
moquette	✔	✔	✔	?	✔	✘	✔	✔	rm	✔	✘	✘	✔
mosca	✔	✔	✘	✔	✘	✘	✔	✔	✘	✔	✘	✘	✘
mosquitto	✔	✔	✔	✔	✔	✔	✔	✔	§	✔	✔	✘	✔
MQTT.js	✔	✔	✔	§	✘	✘	✔	✔	✘	✔	✘	✘	✔
MQTTnet	✔	✔	✔	§	§	§	✔	✔	§	§	§	rm	✔
MqttWk	✔	✔	✔	✔	✔	?	✔	✔	✔	✔	✘	✘	✔
RabbitMQ	✔	✔	✘	SASL	✘	✘	✔	✔	✔	✔	✔	✘	✔
Software AG Universal Messaging	✔	✔	✔	✔	§	✘	✔	✔	§	rm	✘	✘	✔
Solace	✔	✔	✘	Basic, client certificate, Kerberos	§	✔	✔	✔	✔	✔	✘	✘	✔
SwiftMQ	✔	✔	✔	✔	✔	✘	✔	✔	✔	✘	✔	✘	✔
TraferoTstack	✔	✔	✔	✔	✘	✘	✔	✔	✘	✘	✘	✘	✘
VerneMQ	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✘	✔

键

• ✔意思是:支持
• ✘的意思是:不支持
• 吗?意思是:未知
• §意思是:看到局限性
• rm的意思是:路线图(计划好的)

已弃用或停止使用的软件/服务

• 2lemetry被亚马逊AWS秘密收购，见techcrunch的文章。
• Apache ActiveMQ Apollo停止运行，见此链接。
• JoramMQ似乎要停产了。
• IBM物联网消息网关现在是IBM Watson物联网平台。
• mosca 停用。
• RSMB现在是软件公司通用消息。然而，文档非常糟糕。
• TraferoTstack自2017年以来没有更新，所以没有真正维护。

限制

• AWS 物联网服务保留了一些以美元开始的主题。
• ClearBlade 保留了一些从$开始的主题。
• mosquitto  通过后台(redis, amqp等)实现mosquito to聚类。
• MQTT.js 将接受提供了用户名和密码的连接，但并不实际验证该连接。
• Software AG Universal Messaging 传递提供了主动/主动集群(通过专有协议)和桥接(通过专有协议)。
• Solace  ”确实为经纪人之间提供了一个专有的桥梁解决方案。
• MQTTnet提供了客户机和服务器实现。所有特性都可以根据需要进行扩展(或保留)。它主要针对。net开发人员来构建他们的自定义服务器和客户端实现。然而，这个标准已经有很多可用的功能。

 

这需要扩大。请在此表中添加关于已知代理的已知信息，并包括任何已知的限制。

对于代理比较(尽管它现在肯定已经过时了)，还请参见https://github.com/mqtt/mqtt.github.io/issues/37和所附的PDF文件。

 

原文：https://github.com/mqtt/mqtt.github.io/wiki/server-support

本文：http://jiagoushi.pro/node/1105

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

 

最近在Exadel，我们遇到了一个有趣的挑战，对物联网的开发者。因为IoT应用程序获得了如此多的动力，所以有越来越多的选择如何开发它们。对于设备通信，两个专门的竞争协议脱颖而出：消息队列遥测传输（MQTT）和约束应用协议（CoAP）。它们都设计为轻量级，并仔细使用稀缺的网络资源。两者都在正确的环境中使用，但问题是，由于物联网发展的相对发展，人们不知道这些协议是什么或何时使用。

这些不是每个人使用的标准Web协议。

鉴于我们自己内部的对话，我决定帮助我们解释这些。首先，我们来看看这些协议是什么。

什么是MQTT？

对于外行人来说，MQTT很像Twitter。这是一个“发布和订阅”协议。您可以订阅某些主题并发布在其他主题上。您将收到有关您订阅的主题的消息，并且订阅您发布的主题的人将收到这些消息。当然有区别。例如，您可以通过保证交付来配置协议更可靠。发布/订阅系统利用一个经纪人，为了进一步推出类比，Twitter平台本身将根据您的订阅偏好过滤消息。

什么是CoAP？

CoAP更像是传统的基于网站的业务，如亚马逊。您要求资源（亚马逊示例中的页面和搜索结果），并且偶尔还会提交您自己的数据（进行购买）。 CoAP被设计为看起来像是兼容HTTP，它支持大多数互联网，因为我们目前知道的。 CoAP可以利用代理服务器，并将其转换成HTTP，或者根据环境限制直接与设计为使用CoAP的特殊服务器进行通信。

你什么时候使用它们？

你可能都在问的问题是，“如果他们很相似，我应该何时使用一个对另一个？”

由于发布/订阅体系结构与中间商中介，MQTT是广域网（WAN，互联网）上的设备之间的通信的理想选择。它在带宽有限的情况下是最有用的，例如远程现场站点或其他缺乏强大网络的区域。 MQTT是Azure和Amazon服务产品的一部分，因此它具有很多已建立的架构，使其易于适应当前的开发人员。

在CoAP的情况下，最强的用例是与HTTP的兼容性。如果您有一个基于Web服务的现有系统，那么在CoAP中添加是一个很好的选择。它建立在用户数据报协议（UDP）上，这在一些资源有限的环境中是有用的。由于UDP允许广播和多播，您可以使用较少的带宽潜在地传输到多个主机。这使得它对于设备需要快速交流的本地网络环境很好，这对于一些M2M设置是传统的。

如果物联网开发人员正在使用将利用现有Web服务器架构的设备，开发人员将使用CoAP。但是，如果开发者正在构建一个设备真正“仅报告”的东西 - 也就是说，它被丢弃在网络上，只需要将数据报告回服务器 - CoAP将会更好。其他用途，如云架构，可能最好用MQTT完成。

MQTT和CoAP的未来

随着时间的推移，对于其他协议，使用或行业采用趋向于向更自由和包容的平台迁移，除非非包容性平台更好。 MQTT和CoAP都是开放标准，任何人都可以实现。 CoAP由标准机构启动，而不是由私有公司（包括IBM）设计的MQTT。 CoAP被设计为处理资源有限的环境，可能是它成为赢家，但是目前MQTT似乎处于领先地位。 MQTT背后有显着的动力 - 大云玩家已经选择了这一势头，或者至少选择它。此外，许多商业用例需要MQTT（存储和转发，集中式主机）的功能。然而，一种可能性是，一些围绕HTTP（例如移动应用程序开发）进行标准化的软件开发可以开始利用CoAP来处理外围设备，并与后端通信，以帮助减少不良连接带宽。

最终，这些协议可以通过互联网有效部署在不同的应用程序中。我们知道有特定的使用案例，其中每个都是最好的，但是我们也知道，物联网和物联网设备将会在复杂性和普及性方面继续发展。对于开发人员来说，了解应用程序的关键差异不仅可以实现更好的初始部署，而且可以为今后的开发工作奠定坚实的基础。

说实话：物联网仍然是一个涉及新技术的新市场，适用于整个物联网空间的标准是罕见的。这是新技术的预期;正如ZDNet的报告，利用企业中的物联网指出：“在物联网的许多领域，毫无疑问，在标准竞争中将会摆脱和整合，而另一个难以置信的CIO则要关注。” [1]

那么你如何利用物联网，你从哪里开始？

实际物联网

在开始物联网项目之前，您将需要放置几个东西。这些包括能够管理设备和数据的跨学科IT组织，确保诸如集成，合规性和安全性等问题成为头脑的系统 - 可能使用沙箱方法 - 并确保您的基础设施可以处理该数据，除非当然，您打算使用云基础设施。

组织买入将是至关重要的，这反过来意味着需要建立稳固的业务案例，以及衡量投资回报率的方法。

总是会有一些行业部门倾向于选择新技术并与之一起运行。然而，在涉及物联网方面，行业经常被认为比较保守，导致了物联网革命。

物联网在行动

对于制造而言，返回有关现实世界的信息的设备只是当前流程的演变。运输行业受益于传感器数据，从而实现预测性维护，物流效率更高，燃油消耗更低。能源公司已投入巨资从智能电表（无需电池）到遥控器和仪表上的传感器。非盈利性减肥SIG [2]的IEEE研究员兼首席执行官威廉·韦伯（William Webb）表示：“石油泵破裂的几分钟内收入的损失是巨大的，所以值得安装IoT系统。

医疗保健是一个不断发展的行业，受益于监控远程设备的能力，包括安装在病人身边的设备，在家中使用IoT设备也在增加。

云可以如何帮助

考虑如何建立自己的物联网专家团队，以及购买和配置支持它所需的基础设施，除了上述不可避免的问题外，可能足以给出任何CIO的意图。

新技术不仅总是昂贵，正确的技能往往是罕见的，所以这是一个更大的挑战。相反，依靠您的系统集成商，他们将能够使用基于云的解决方案来定制解决方案，至少在最初阶段就有很大的意义。

云提供商正在通过新的解决方案来包装其基础设施，以利用物联网。例如，一家领先的大型提供商提供了一套可提供预测性维护的套件，可让您预测设备故障并系统地防止设备故障。它还提供IoT驱动的远程监控，其中涉及从资产收集数据，并使用该数据来触发自动警报和操作，如远程诊断，维护请求和其他操作流程。

这些服务的主要优点是手动，时间密集的程序现在可以动态，快速和自动化。几乎任何地方的资产都可以从远程监控，使用智能传感器和设备的实时数据。这反过来可以更好地了解操作状态，使您能够快速自动地响应当前的状况。

简而言之

虽然标准仍然难以捉摸，直到IT行业开始发展 - 通常当IT制造商决定采用标准来扩大市场和增加收入时，这不应妨碍您组装一个提供稳健投资回报率的协调一致的基础设施的能力到业务。集成商和云提供商已经在提供工作解决方案，为什么不使用它们？

当谈到物联网（IoT），许多开发者从微控制器、片上系统板、单板计算机、传感器和各种其他电子元件来思考。而设备无疑是物联网的基础，连接的解决方案的核心价值在于这些设备产生的数据。

设备层仅仅是底层数据平台的冰山一角，而底层数据平台则是水面下的重担。强大的物联网数据平台的关键支柱之一是Apache Kafka，它是一种开源软件，旨在处理大量的数据摄取。它充当数据中心中由Apache storm、Apache spark和Apache hadoop集群提供支持的数据处理管道的网关。

如果你是一个将物联网作为职业选择的开发者，那么现在是你开始投资Apache kafka的时候了。本文探讨了Apache kafka在部署可伸缩物联网解决方案中所扮演的角色。

Kafka：传感器数据的高性能摄取层

物联网设备包括能够生成多个数据点的各种传感器，这些数据点以高频率采集。一个简单的恒温器每分钟可以产生几字节的数据，而一辆连接的汽车或风力涡轮机在几秒钟内就可以产生千兆字节的数据。这些海量数据集被摄取到数据处理管道中，用于存储、转换、处理、查询和分析。

每个数据集由多个表示特定度量的数据点组成。例如，连接的暖风、通风和空调（HVAC）系统将报告环境温度、所需温度、湿度、空气质量、鼓风机转速、负荷和能耗指标。

在一个大型购物中心，这些数据点经常从数百个hvac收集。由于这些设备的功能可能不够强大，无法运行完整的TCP网络堆栈，因此它们使用诸如Z-Wave和ZigBee之类的协议将数据发送到能够聚合数据点并将其摄取到系统中的中央网关。

网关将数据集推送到Apache-Kafka集群，其中的数据采用多条路径。需要实时监控的数据点经过热路径。在我们的HVAC场景中，实时跟踪温度、湿度和空气质量等指标以采取纠正措施非常重要。这些数据点可以通过Apache storm和Apache spark集群进行近实时处理。

负载和功耗等指标在一段时间内收集后进行分析。通过批处理过程收集和分析的这些数据点通常采用数据处理管道的冷通道。MapReduce作业可以在Hadoop集群中运行，用于分析hvac的能效。

不管数据点采用什么路径，它们都需要被摄取到系统中。apachekafka充当处理大量数据集的高性能数据摄取层。负责热路径和冷路径分析的数据处理管道组件成为apachekafka的订户。

Kafka vs.MQTT

apachekafka不是MQTT的替代品，MQTT是一种通常用于机器到机器（M2M）通信的消息代理。卡夫卡的设计目标与MQTT有很大不同。

在物联网解决方案中，设备可分为传感器和执行器。传感器生成数据点，而执行器是可以通过命令控制的机械部件。例如，房间中的环境照明可用于调整LED灯泡的亮度。在这种情况下，光传感器需要与LED通信，这是M2M通信的一个例子。MQTT是为传感器网络和M2M优化的协议。

由于Kafka不使用HTTP进行接收，所以它提供了更好的性能和规模。

由于MQTT是为低功耗设备设计的，它无法处理海量数据集的摄取。另一方面，Apache kafka可以处理高速数据摄取，但不能处理M2M。

可扩展的物联网解决方案使用MQTT作为显式设备通信，同时依赖Apache Kafka来接收传感器数据。也可以将Kafka和MQTT桥接起来，以便摄取和M2M。但是建议将设备或网关配置为Kafka生产者，同时仍然参与由MQTT代理管理的M2M网络，从而使它们保持分离。

Kafka与HTTP/REST

apachekafka公开了一个基于二进制协议的TCP端口。推送数据的客户机启动套接字连接，然后写入一系列请求消息并读回相应的响应消息。此协议不需要为每个连接或断开连接进行握手。

由于Kafka不使用HTTP进行接收，所以它提供了更好的性能和规模。客户机可以连接到集群的一个实例来接收数据。这种体系结构与原始TCP套接字相结合提供了最大的可伸缩性和吞吐量。

虽然使用HTTP代理与Kafka集群通信可能很诱人，但建议解决方案使用本机客户机。由于Kafka是用Java编写的，所以本机Java客户机库提供了最好的性能。社区已经为Go、Python甚至甚至构建了优化的客户端库节点.js. Shopify还为Kafka开发了一个名为Sarama的开源Go库。Rackspace的Mailgun团队已经构建了Kafka Pixy，一个Kafka的开源HTTP代理。Python、C#、Ruby和其他语言有多个库。

大多数物联网网关功能强大，足以运行Java、Go或Python。为了获得最佳性能和吞吐量，建议使用本机为Kafka设计的客户端库。

Kafka入门

apache kafka是用Java开发的，它的部署由apache zookeeper管理。任何能够运行JVM的操作系统都可以用来部署Kafka集群。为了测试水，你可以在Docker运行卡夫卡。

如果您不想处理基础设施，可以从云中的托管Kafka服务开始。IBM Bluemix有一个基于Kafka的完全管理的基于云的消息服务MessageHub。Cloud Karafka是公共云中的另一个流式平台，专为Apache Kafka工作负载而设计。 Aiven.io提供hosted Kafka以及InfloxDB、Grafana和Elasticsearch。如果你是一个Salesforce.com网站或者Heroku开发者，你可以在Heroku上利用Kafka。

Apache卡夫卡是许多大数据部署的基础。在本系列的后续文章中，我将介绍Kafka的关键概念、体系结构和术语

原文：https://thenewstack.io/apache-kafka-cornerstone-iot-data-platform/

本文：http://jiagoushi.pro/node/1102

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

Apache Kafka是一个实时流平台，在大大小小的组织中得到了广泛的采用。Kafka的分布式微服务架构和发布/订阅协议使得它非常适合在企业系统和应用程序之间实时移动数据。据统计，超过三分之一的财富500强公司正在使用Kafka。在Github上，Kafka是最受欢迎的Apache项目之一，有超过11K之星和超过500名贡献者。毫无疑问，Kafka是一个开源项目，它改变了企业在云和数据中心内移动数据的方式。

Kafka的架构已经被优化为在系统和应用程序之间以可伸缩的方式尽可能快地流数据。Kafka客户端/生产者与Kafka集群紧密耦合，要求每个客户端知道Kafka集群的IP地址，并直接访问所有单独的节点。在可信网络内部，这允许对代理拓扑进行更改，这意味着可以通过直接使用来自Kafka客户端的多个节点来扩展主题和分区。在大多数情况下，Kafka主题空间也保持相当扁平，因为通常使用多个分区来扩展单个Kafka主题。在Kafka系统中拥有数百甚至数千个主题通常是不可取的，首选的方法是对大多数数据流使用很少的主题。Kafka非常适合在具有稳定IP地址和连接的相同可信网络内的系统之间进行通信。

对于设备连接到公共互联网上的数据中心或云的物联网用例，Kafka架构不适合开箱即用。如果您试图在Internet上使用Kafka从数千甚至数百万设备流数据，那么Apache Kafka架构是不合适的。有许多原因Kafka本身不是很适合物联网用例:

1. Kafka代理需要由客户端直接处理，这意味着每个客户端需要能够直接连接到Kafka代理。专业的IoT部署通常利用负载均衡器作为云中的第一道防线，因此设备只使用负载均衡器的IP地址连接到基础设施，负载均衡器有效地充当代理。如果您希望您的设备直接连接到Kafka，您的Kafka代理必须暴露给公共互联网。
2. Kafka不支持大量的主题。当通过公共Internet连接数以百万计的物联网设备时，通常使用单个和唯一的主题(通常在主题名称中包含一些唯一的物联网设备标识符)，因此可以根据单个客户机的权限限制读写操作。你不希望你的智能恒温器被黑客攻击，那些证书可能被用来窃听系统中的所有数据流。
3. 与物联网协议的客户端库相比，Kafka客户端是相当复杂和资源密集型的。大多数编程语言的Kafka api都非常直接和简单，但是在其内部存在很多复杂性。例如，客户端将使用并维护到Kafka代理的多个TCP连接。物联网的部署通常会限制设备的使用，这些设备需要最小的内存占用，并且在设备端不需要很高的吞吐量。默认情况下，Kafka客户端针对吞吐量进行了优化。
4. Kafka客户端需要一个稳定的TCP连接来获得最好的结果。许多物联网使用案例涉及不可靠的网络，例如联网的汽车或智能农业，因此典型的物联网设备需要不断地重新建立与Kafka的连接。
5. 将数万甚至数百万客户机连接到一个Kafka集群是不寻常的(通常甚至根本不可能)。在物联网使用案例中，通常有大量设备同时连接到后端，并不断产生数据。
6. Kafka缺少一些关键的物联网功能。Kafka协议缺少了诸如《活着》和《遗嘱》等功能。这些特性对于构建一个有弹性的物联网解决方案非常重要，该解决方案可以处理遇到意外连接丢失和网络不可靠的设备。

Kafka仍然为物联网用例带来了很多价值。物联网解决方案创建了大量的实时数据，很适合由Kafka处理。挑战在于:如何将物联网数据从设备连接到Kafka集群?

许多实现物联网用例的公司正在研究集成MQTT和Kafka来处理物联网数据的可能性。MQTT是另一个发布/订阅协议，它已经成为连接IoT设备数据的标准。MQTT标准设计用于通过不可靠的网络连接大量的物联网设备，解决了Kafka的许多限制。具体来说，MQTT是一种轻量级协议，需要在每个设备上占用较小的客户机空间。它可以在不可靠的网络上安全地支持数百万个连接，并在高延迟和低吞吐量环境下无缝工作。它包括物联网功能，如保持活力，最后的遗嘱和遗嘱功能，不同质量的服务水平的可靠消息，以及客户端负载平衡(共享订阅)在其他功能设计的公共互联网通信。主题是动态的，这意味着系统中可以存在任意数量的MQTT主题，在MQTT服务器集群中，每次部署通常多达数千万个主题。

尽管Kafka和MQTT有不同的设计目标，但两者在一起工作得非常好。问题不是Kafka vs MQTT，而是如何将这两个世界集成在一起，形成一个物联网端到端数据管道。为了将MQTT消息集成到Kafka集群中，需要某种类型的桥接器将MQTT消息转发到Kafka。

有四种不同的架构方法来实现这种类型的桥梁:

1. Kafka连接（Kafka Connect）MQTT

Kafka有一个扩展框架，叫做Kafka Connect，它允许Kafka从其他系统摄取数据。Kafka Connect for MQTT充当一个MQTT客户端，订阅来自MQTT代理的所有消息。

如果您没有对MQTT代理的控制权，那么Kafka Connect for MQTT是一个值得追求的方法。这种方法允许Kafka摄取MQTT消息流。

在MQTT中使用Kafka Connect存在性能和可伸缩性限制。如前所述，Kafka Connect for MQTT是一个MQTT客户机，它订阅通过代理传递的所有MQTT消息。MQTT客户机库并不打算处理大量的MQTT消息，因此使用这种方法的物联网系统将存在性能和可伸缩性问题。

这种方法集中了业务和消息转换逻辑，并创建了紧密耦合，这在分布式(微服务)体系结构中应该避免。业界领先的咨询公司Thoughtworks称这是一种反模式，甚至在他们之前的技术雷达出版物中将Kafka归入“持有”类别。

2. MQTT代理

另一种方法是使用代理应用程序，它接受来自物联网设备的MQTT消息，但不实现发布/订阅或任何MQTT会话特性，因此不是MQTT代理。物联网设备连接到MQTT代理，然后该代理将MQTT消息推送到Kafka代理。

MQTT代理方法允许在Kafka部署中完成MQTT消息处理，因此可以从单个控制台完成管理和操作。MQTT代理通常是无状态的，因此通过添加代理的多个实例，它(理论上)可以独立于Kafka集群进行伸缩。

MQTT代理的限制是它不是真正的MQTT实现。MQTT代理不是基于发布/订阅的。相反，它在设备和Kafka之间创建了一个紧密耦合的流。MQTT发布/订阅的好处是，它创建了一个松散耦合的端点系统(设备或后端应用程序)，可以在每个端点之间通信和移动数据。例如，MQTT允许两个设备之间的通信，例如两个连接的汽车可以彼此通信，但是MQTT代理应用程序只允许从一辆汽车到Kafka集群的数据传输，而不允许与另一辆汽车的数据传输。

一些Kafka MQTT代理应用程序支持QoS级别等特性。值得注意的是，只有在MQTT客户端重新连接到相同的MQTT代理实例时，才可能在连接丢失后恢复QoS消息流，而这是不可能的，前提是使用负载均衡器，该均衡器使用最少连接或循环策略来实现可伸缩性。因此，在MQTT中使用QoS级别的主要原因(即没有消息丢失)仅适用于稳定连接，这在大多数物联网场景中是一个不现实的假设。

使用这种方法的主要风险是代理不是功能完整的MQTT代理，因此它不是MQTT规范定义的MQTT实现，只是实现了一个很小的子集，因此它不是一个标准化的解决方案。为了在MQTT客户机中正确地使用MQTT，需要一个功能齐全的MQTT代理。

如果消息丢失不是一个重要因素，并且没有使用为可靠的物联网通信而设计的MQTT特性，如果您只想通过Internet单向地向Kafka发送数据，那么代理方法可能是一个轻量级的替代方法。

3.构建您自己的自定义桥接

一些公司建立了他们自己的MQTT到Kafka桥。典型的方法是使用开源MQTT客户端库和开源Kafka客户端库创建应用程序。自定义应用程序负责在MQTT代理和Kafka实例之间调换和路由数据。

这种方法的主要挑战是，自定义应用程序通常没有设计成容错和弹性。如果物联网解决方案要求和端到端保证至少一次或确切一次消息传递，这就变得很重要。例如，设置为服务质量级别1或2的MQTT消息发送到自定义应用程序将确认收到消息。但是，如果自定义应用程序在将消息转发给Kafka之前崩溃，则消息将丢失。类似地，如果Kafka集群不可用，自定义应用程序将需要缓冲MQTT消息。如果定制应用程序在Kafka集群恢复可用之前崩溃，所有缓冲的消息将丢失。要解决这些问题，定制应用程序将需要大量的开发工作，构建与Kafka和MQTT代理中已经发现的技术类似的功能。

4. MQTT代理扩展

最后一种方法是扩展MQTT代理，以创建包含本机Kafka协议的扩展。这允许MQTT代理充当一流的Kafka客户机，并将物联网设备数据流传递给多个Kafka集群。

要实现这种方法，您需要访问MQTT代理，代理需要能够安装扩展。

这种方法允许物联网解决方案使用本地MQTT实现和本地Kafka实现。物联网设备使用MQTT客户机将数据发送到功能齐全的MQTT代理。MQTT代理被扩展为包括一个本地Kafka客户机，并将MQTT消息置换到Kafka协议。这使得物联网数据可以同时路由到多个Kafka集群和非Kafka应用程序。使用MQTT代理还将提供对物联网设备所需的所有MQTT特性的访问，例如遗嘱和遗嘱。MQTT代理(如HiveMQ)是为高可用性、持久性、性能和弹性而设计的，因此消息可以在Kafka不可写时在代理上缓冲，因此重要消息不会从物联网设备中丢失。因此，这种方法提供了真正的端到端消息传递保证，即使是在不可靠的网络、公共Internet通信和不断变化的网络拓扑(在容器化部署中经常看到，例如Kubernetes)。

用于Kafka的HiveMQ企业扩展

在与HiveMQ客户的对话中，一些操作集群具有数百万台设备和非常高的消息吞吐量，我们看到需要为Kafka创建MQTT代理扩展。我们的客户希望从MQTT和Kafka协议的本地实现中受益，因为这两个协议都有所有的交付保证。因此，我们很高兴地宣布Kafka的HiveMQ企业扩展。

我们的客户看到了MQTT和Kafka联合解决方案的巨大价值。他们将Kafka视为在数据中心或云环境中处理和分发实时数据的优秀平台。他们希望使用MQTT和HiveMQ将数据从设备移动到不同的后端系统。后端系统包括Kafka和非Kafka系统。他们还知道，如果他们试图连接数以百万计的设备，比如连接的汽车，他们需要使用MQTT的本机和经过实战测试的实现，比如HiveMQ。

用于Kafka的HiveMQ企业扩展在HiveMQ代理中实现了本地Kafka协议。这允许MQTT消息与单个Kafka集群或多个Kafka集群同时无缝集成。它100%支持整个MQTT 3和MQTT 5规范。我们甚至可以将潜在的数百万个MQTT主题映射到数量有限的Kafka主题。最后，我们扩展了HiveMQ控制中心，使其能够监视写入Kafka的MQTT消息。

我们很高兴能将这个新产品带给我们的HiveMQ客户。这是在物联网用例中使用Apache Kafka的最佳方法。

 

参考：http://jiagoushi.pro/node/1099

讨论：请加入知识星球【首席架构师圈】或者小号【ca_cto】

物联网数据很复杂，需要多个用户访问，所以不要犯创建数据孤岛的错误。

几乎在每个行业，都有一个由物联网数据驱动的数字化转型正在进行中。重要的是要认识到物联网不是关于事物的;而是那些东西创造和收集的数据。组织依靠这些数据提供更好的用户体验，做出更明智的业务决策，并最终推动其增长。

然而，如果没有一个可靠的数据库来处理物联网设备产生的大量数据，这一切都是不可能的。关系数据库以灵活、易于使用和成熟而闻名。它们并不特别出名的是规模，这促使了NoSQL数据库的创建。你可能知道也可能不知道，有一些方法可以克服这个缺点。

另一件需要注意的事情是，物联网数据本质上是时间序列。通过使用像TimescaleDB这样的时间序列数据库，组织可以利用隐藏在机器生成数据中的洞察力来构建新特性、自动化流程和提高效率(稍后将对此进行更多介绍)。通常，工程团队最终会将数据存储在多个数据库中:元数据存储在关系数据库中，时间序列数据存储在NoSQL存储中。不要这样做。

下面，我们将概述您希望在NoSQL之上使用关系数据库的主要原因，并解释TimescaleDB + PostgreSQL可以为物联网提供的优势。

利用SQL及其生态系统

物联网数据需要多样化的、可定制的摄食管道，这需要一个具有广泛生态系统的数据库。要满足这些需求，开发人员只需查看SQL即可。

关系数据库和SQL密不可分，许多跨组织的人员(例如内部数据分析师、应用程序开发人员或希望实时访问数据的外部用户)通常已经了解SQL。例如，在制造业中，有些团队可能想要监视设备维护和预测故障，有些团队可能想要跟踪生产率和运输物流数据，等等。SQL使其变得容易。

此外，还有一些非常酷的功能，如:

• 连接:基于两个或多个表之间的相关列，将这些行组合在一起
• 聚合:将多个行的值分组在一起，形成一个汇总值(即最小、最大、AVG)
• 窗口函数:对一组行进行操作，并从底层查询中为每一行返回一个值(即PARTITION BY、ORDER BY)。
• 公共表表达式(CTEs):简化复杂的连接和子查询(即使用)
• ROLLUPS: GROUP BY子句的扩展，允许您使用单个查询生成多个分组集

此外，开发人员通常希望在现有的物联网基础设施上构建应用程序。SQL兼容许多管理工具，流管道(如Kafka或RabbitMQ)、消息传递协议(如MQTT)、可视化工具(如Seeq)、工业自动化平台(如Ignition)，以及用于处理地理空间和其他数据类型的扩展。

模式(大纲)是一件好事

对于关系数据库，您可以使用模式来帮助进行数据建模。虽然“无模式”数据库看起来似乎更容易入门，但它们最终会导致重大的技术债务。用户通常必须预先就如何存储他们的数据做出设计决策，而这些决策在未来很难更改。这意味着，如果新的查询模式需要不同的设置来提高性能，那么它们将得不到很好的支持。

另一方面，使用SQL预先构建模式实际上支持复杂的查询。用户还可以使用一组DDL(数据定义语言)命令来调整和更新模式。但是，正确地建模数据以提高性能是很重要的。为给定的工作负载创建适当的索引和表模式可以显著提高性能。相反，设计错误的模式会导致显著的性能下降。

本质上，你需要的是一种灵活的模式，特别是在存储半结构化数据时(例如，存储来自收集不同测量值的物联网传感器的读数)。您还需要一个能够灵活地管理和访问数据的数据库。特别是在物联网中，您收集数据的设备并不总是在线的，从而导致批量上传的数据次序混乱。您还可能需要更新不正确的传感器测量值。关系模型很好地支持所有这些函数。

消除数据孤岛

我们已经提到了这样一个事实，即组织中很多人都知道SQL，它允许多个用户访问数据。我们经常从客户那里听到，他们希望将时间序列数据库与完整的关系系统结合在一起，并且希望能够连接这些数据。

幸运的是，关系数据库支持连接并消除了在多个位置存储数据的需要。通过这样做，组织还可以节省操作多个系统的开销成本。此外，它们还可以避免与维护独立数据库相关的完整性问题，这就引出了我们的下一点。

依赖关系数据库获得可靠性

许多存储敏感数据的组织依靠关系数据库来保证信息的安全。毕竟，关系数据库早在70年代就出现了，并且在保证财富500强公司数据安全方面有着良好的记录。

物联网应用程序通常必须处理大量复杂的查询和事务。使用关系数据库，您可以确保这些事务将是进程的可靠性，这要归功于ACID(原子性、一致性、隔离性、持久性)。如果您不熟悉，那么可以告诉您，ACID是修改数据库时使用的一组属性。它们保证即使在遇到错误、断电、崩溃等情况下，事务也是有效的。

物联网选择PostgreSQL + TimescaleDB

如果您正在寻找用于物联网的关系数据库，我们建议您选择PostgreSQL。虽然我们似乎有些偏颇，但PostgreSQL的受欢迎程度依然坚定，并且连续第二次被db引擎评为年度最佳DBMS:

PostgreSQL首次发布于1989年，今年已经30岁了，它的人气达到了顶峰，没有任何老化的迹象，拥有一个非常活跃的社区。由于其稳定性和特性集，PostgreSQL已经成为众多开发人员首选的数据存储。”

虽然还有其他的关系数据库管理系统，但PostgreSQL和TimescaleDB为物联网开发人员提供了显著的优势。

总结:

原文：https://blog.timescale.com/blog/use-relational-database-instead-of-nosql-for-iot-application/

本文：http://jiagoushi.pro/node/1333

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

为物联网解决方案选择正确的数据库平台是一项艰巨的任务。首先，物联网解决方案可以跨地理区域分布。与集中式的基于云的解决方案相反，更多的解决方案正在采用边缘雾计算和云计算的组合。因此，您的数据库平台必须为您提供在边缘处理数据以及在边缘服务器和云之间进行同步的灵活性。

其次，根据您的物联网使用情况，您需要的数据库功能可能包括实时数据流、数据过滤和聚合、接近零延迟的读取操作、即时分析、高可用性、地理分布、模式灵活性等等。本文介绍了为物联网解决方案选择正确的数据库平台的四个步骤:

步骤1 确定解决方案的数据需求

物联网解决方案依赖于从联网设备中收集和处理数据，做出智能决策，如触发通知或动作，计算实时分析，从历史数据中收集模式，等等。

为了便于讨论，在通用的物联网解决方案中，可以在整个企业中安装传感器和执行器。成千上万的传感器和执行器与一台edge服务器相连。物联网解决方案不断从所有传感器收集数据，做出实时决策来控制传感器和执行器，向系统监视器发出异常活动警报，并为最终用户提供分析的历史视图。

在决定使用哪些服务和与之配套的数据库之前，有必要清楚地了解如何使用数据以及在何处使用数据。一些问题可以帮助理解和优先考虑你的数据需求:

• 哪些数据处理和决策被委托给边缘服务器?
• 云解决方案是部署在一个地区，还是分散在多个地区?
• 从设备到边缘服务器和从边缘服务器到中央服务器传输的数据量是多少?估计的峰值容量是多少?
• 物联网解决方案是否控制设备或致动器?如果是，它们需要实时响应吗?
• 从历史数据中获得的业务洞察力是什么?

步骤2 将解决方案分解为独立的软件服务

在此步骤中，您将设计执行独立的特定任务的软件服务或组件。

当将前面描述的样例物联网解决方案分解为独立的服务时，可以得到图2所示的设计。物联网解决方案本身是地理分布的，其中一些组件部署在边缘网络，其余组件在一个集中位置。

现在让我们将架构分解为服务，并分析它们的职责和数据需求:

数据摄取

目的:收集和存储设备日志和消息。

数据库需求:支持高速写操作，因为数据可能以突发的方式到达，确保数据在不寻常的情况下不会丢失。

边缘分析

用途:对输入数据执行数据转换、分类、聚合、过滤和功能。它负责在边缘进行实时决策。

数据库需求:支持高速读写与亚毫秒延迟;提供工具和命令来对数据执行复杂的分析计算。

设备管理器

用途:向设备传递信息。

数据库需求:以最小的延迟访问和向设备发送消息。

系统分析

目的:从边缘服务器收集数据，执行数据转换和分析操作。

数据库需求:提供对数据执行分析计算的命令，并根据分析引擎的需要长时间存储数据。

C&C (命令和控制)仪表板

目的:提供物联网生态系统当前状态的可视化表示。

数据库需求:保持数据的当前和准确，读取数据的延迟小于毫秒。

商业智能

用途:从历史数据运行报告、查询和推断。

数据库需求:长时间存储数据，节约成本;提供查询和分析数据的工具。

物联网数据流出口

用途:将数据规范化为一种通用格式，并将其推送给订阅服务器。

数据库需求:高效执行数据转换操作的能力;支持发布和订阅功能。

 

步骤3:根据数据需求对服务进行分组，并选择正确的数据库

下一步是根据每个服务的数据选择正确的数据库。图3将我们的物联网示例中的服务连接到图中，根据数据在数据库中停留的时间和服务所需的数据读/写速度对它们进行分类。

您将看到数据不断进出数据摄取服务器，在数据库中停留的时间非常短。同时，数据的到达量大，速度快。因此，我们需要一个具有低延迟的高速数据库来保存用于摄入服务的数据。另一方面，商业智能服务依赖于历史数据。

下一步是对具有类似数据访问特征的服务进行分组，目标是限制数据库的数量(多余的数据库和不符合您需求的数据库)，从而减少操作开销。

在图4中，我们将示例服务分组到两个主数据库中—一个热数据库和一个冷数据库。保存热数据的数据库部署在靠近物联网设备的位置，以最小化网络延迟。热数据和冷数据的数据库选择是:

热数据库:由于RAM的成本越来越便宜，内存中的数据库通常是一个不错的选择。内存中的数据库以最小的延迟交付数据读写能力。当选择一个热数据库时，这些额外的功能和能力将帮助您缩小选择范围:

• 数据格式的灵活性——帮助您支持广泛的设备和通信格式
• 查询功能——使您能够实时运行高效的查询
• 消息传递和排队——驱动通信和数据交换
• 分层内存模型-提供一个经济有效的内存模型，但高性能
• 高可用性和灾难恢复-帮助您保持业务的所有时间
• 地理分布-服务地理分布的物联网部署
• 二进制安全-帮助您保存二进制数据

冷数据库:物联网解决方案的历史数据可能增长到多个tb，在某些情况下可能超过一个pb。存储历史数据的流行选择包括在普通硬件上存储解决方案。查询通常遵循map-reduce模式。通常，历史数据也会在搜索引擎中建立索引，用于模式匹配和数据聚合。如果您要将数据存储在云中，请与您的云服务提供商联系，在您所在的地区，哪种数据存储方案最划算。

第四步:评估成本、资源效率

将数据库分为热数据库和冷数据库有助于缩小数据库选择范围。对于大多数物联网用例，一个高速数据库可以满足热数据库的所有需求。对于冷数据库，选项可能从关系数据库到数据湖。设计人员经常犯的一个错误是为每个服务创建具有专门数据库的多语言体系结构。这增加了应用程序堆栈的复杂性以及操作开销和成本。

拥有一个数据库的总成本是许多参数的函数。数据库本身的成本只是成本的一小部分。以下是一些费用:

• 数据库许可证成本:该成本可能与cpu数量、集群中的碎片数量、数据库大小、吞吐量(每秒最大操作数量)、时间(年、月、小时等)、高可用性和恢复特性、云的多个区域的可用性等有关。如果您使用的数据库可以作为开放源码软件使用，根据许可证的类型，数据库成本甚至可能为零。
• 基础设施成本:基础设施成本取决于数据库的资源效率。例如，一个轻量级、线程安全的数据库可能只使用两个商用服务器每秒执行100万次读/写操作，而传统数据库可能需要更多的服务器才能得到相同的结果。除了数据库效率，硬件成本还取决于吞吐量、cpu数量、RAM、数据大小、闪存、网卡等。用于高可用性的数据库体系结构也发挥了作用。例如，基于仲裁的故障转移架构将只需要一个备用服务器副本，但非基于仲裁的架构将需要两个数据副本，以避免分裂大脑。
• 数据丢失成本:为数据丢失提供适当的保险是极其重要的，特别是对于商用物联网解决方案。您丢失数据的总成本为:
  • 亏损的业务
  • 数据丢失的概率*恢复数据的成本

您可以使用数据库供应商提供的适当SLA来抵消部分成本。

• 操作开销:自动化是成功的咒语。如果数据库提供控制来自动化部署、配置、故障转移、扩展、数据分区、备份和恢复、监视和警报等操作，那么将有助于高效地操作。

结论

当为下一代物联网解决方案选择正确的数据库时，很容易迷失在现有的大量数据库中。但是，如果将解决方案分解为组件服务并理解它们的数据库需求，就可以有效地缩小数据库选择范围。大多数物联网解决方案都依赖于热数据库进行实时数据收集、处理、消息传递、分析，而冷数据库用于存储历史数据和收集商业智能。这将使架构简单、精简和健壮。

最后需要说明的是，Redis实验室赞助的开源内存数据库Redis是物联网解决方案的热门数据库。它被物联网解决方案广泛用于数据摄取、实时分析、消息传递、缓存和许多其他用例。

 

原文：https://thenewstack.io/4-steps-to-select-the-right-database-for-your-internet-of-things-system/

本文：http://jiagoushi.pro/node/1332

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

面对现实吧。建立物联网产品路线图难度要比为“正常”技术产品制定路线图要困难得多。

这是因为IoT产品是复杂的系统。为了创建一个工作的解决方案，物联网技术栈的所有层 - 设备硬件，设备软件，通信，云平台和云应用都需要一起工作。就像在一个管理五个产品一样，你的路线图需要成为让所有利益相关者符合你的愿景的胶合剂。

物联网路线图 - 您的利益相关方和团队对齐的关键

物联网路线图需要以所有利益相关者有意义的方式展示产品方向以及新功能的影响。您的利益相关者可能来自销售，营销，执行团队，工程等。他们都有不同的需求和不同层次的了解产品如何组合在一起。

事实上，IoT引入了额外的复杂性，因为即使技术实现可能分为多个组。根据您公司的结构，您可能会有专门的硬件与软件团队，嵌入式和云开发等。没有任何一个团队将有一个整体的理解，这使您更加重要（和您的路线图）沟通完整的图片。

由于这种复杂性，管理物联网产品类似于管理产品组合，区别在于您的投资组合中的所有产品需要一起工作以形成一个凝聚力的解决方案。不是一件容易的事情

构建物联网产品路线图的关键是平衡端到端产品的高级视图，并在物联网技术栈的每一层进行更详细的视图。这样，您就可以为不同的利益相关者提供适当的信息，确保没有人看到大局。

建议阅读：物联网：产品经理入门

建立高层次的物联网产品路线图

我们用一个例子来说明物联网产品路线图的所有运动部分。假装你的公司建造工业水泵。

在与很多客户和销售人员交谈之后，您发现客户的一个主要关注点是始终保持业务运行。他们想知道泵是否即将失效，以便他们可以主动地订购部件并安排服务。这将减少停机时间并节省很多钱。这种“预测维护”对您的客户非常有价值，他们愿意付出很多代价。

研究解决方案与工程，你会知道，随着泵的老化，它开始振动。振动越多，失败越紧。因此，如果您能够监测泵振动并对该数据执行分析，则可以预测故障。通过这些信息和一些业务尽职调查，您确定这是一个很好的解决方案，您可以将其放在内部买入的路线图中。

您的高级路线图可能看起来像这样。

如您所见，这与非IoT产品的路线图没有什么不同。这里面临的挑战是，您的利益相关者（高管，销售，营销和工程部门）很难理解构建此功能以及最终产品的功能。也很难理解为什么第一版将需要6个月，而版本＃2和＃3将会更短。

使用故事映射来增强您的物联网路线图

对于您的IoT路线图传达完整的故事，您需要提供另一个级别的详细信息，描述物联网技术栈中高层路线图的功能。

我发现故事映射是深入下一个细节层级的好方法。我喜欢将故事映射与IoT技术栈结合在一起，以显示功能如何与端对端IoT产品的各个层对齐。

结果是一个比“产品积压”更高的可视化，但为所有团队提供足够的信息来了解大局。这一观点还使团队能够了解计划功能如何与他们需要做的日常工作相关。

以下是这种方法将如何寻找我们的“智能泵”的例子。从这个观点来看，更容易解释需要完成的工作来支持预测性维护功能。请注意，上一个路线图中高级功能的名称如何成为每个版本的主题。这有助于您的团队关注大局，同时关注较小的细节。

请注意，并非所有图层都必须受到每个版本的影响。在这个例子中，发布＃1后的“通信”层没有任何功能。此示例假定“通信”层中的版本＃1功能将能够支持版本＃2和＃3的功能。

从这个可视化的角度来看，很容易看到第1版是影响设备硬件的唯一版本。因此，很容易解释为什么第1版将比其他版本更长。

您还可以看到在版本＃2和＃3中影响较少的图层。初始版本将是最长的，因为您需要构建大量的基础设施。一旦建立了初始的“管道”，那么您可以以更快的速度添加其上的功能。您可以使用此工具来解释演变。

建议阅读：物联网的产品管理框架

使用路线图协调工程

您还可以使用故事映射路线图来协调跨越物联网技术栈的各个层次的多个工程团队。每个团队都需要分享产品所在的统一愿景。但与此同时，他们需要了解他们特定团队的未来工作。该路线图可以帮助您实现两个目标。

如下图所示，您可以使用“垂直切片”为多个版本的每个工程团队创建特定的路线图。只要数据格式和层之间的接口被明确定义，这种方法将使每个团队能够独立工作，并使进度更快。

底线

作为产品经理，在整个公司沟通产品愿景时，您将永远面临挑战。 这是一项艰巨的任务，但这可能是我们角色中最重要的功能。 这篇文章中概述的方法为您提供了一个非常强大的沟通工具，您可以使用它来清楚地表达您的产品想法并使每个人都对齐。 结果：提高透明度，从而实现更好的沟通，快乐的团队和愉快的客户。

物联网产生大量的数据，包括流数据、时间序列数据、RFID数据、传感数据等。要有效地管理这些数据，就需要使用数据库。物联网数据的本质需要一种不同类型的数据库。以下是一些数据库，当与物联网一起使用时，会给出非常好的结果。

物联网可以看作是一个网络，在这个网络中，各种事物通过一个共同的平台相互连接。只是想象一个场景,在该场景中,每一个设备在家里和工作场所的连接,和一个世界,空调在房间外面的温度上升时自动降低其温度,当在任何公共集会的人数很容易知道,当一个人的健康可以每天监控参数。这就是物联网可能带来的影响。

物联网目前的状态是非常零散的。有不同的公司和组织正在为他们的客户或他们的个人需求建立自己的平台。但是，目前还没有一种通用的平台，可以让所有设备(无论它们是哪家公司的)通过用户友好的界面相互连接。

据估计，未来5年，物联网设备的数量将达数万亿。

物联网需要数据库吗?

物联网带来了许多繁琐的挑战，尤其是在数据库管理系统领域，比如实时整合海量数据、处理流中的事件以及处理数据的安全性。例如，应用于智能城市的基于物联网的交通传感器可以实时生成大量的交通数据。

数据库在充分处理物联网数据方面扮演着非常重要的角色。因此，适当的数据库与适当的平台同等重要。由于物联网在世界上不同的环境中运行，选择合适的数据库变得非常具有挑战性。

在为物联网应用选择数据库之前应该考虑的因素是:

1. 大小、规模和索引
2. 处理海量数据的有效性
3. 用户友好的模式
4. 可移植性
5. 查询语言
6. 流程建模和事务
7. 异构性和集成
8. 时间序列聚合
9. 归档
10. 安全和成本

物联网中的数据类型有:

1. RFID:射频识别
2. 地址/惟一标识符
3. 过程、系统和对象的描述性数据
4. 普适环境数据和位置数据
5. 传感器数据:多维时间序列数据
6. 历史数据
7. 物理模型:作为现实模板的模型
8. 执行器状态及控制命令数据

适合物联网的数据库

InfluxDB

InfluxDB:流感数据库首次发布于2013年，是最近的数据库之一。该数据库完全基于键值数据库LevelDB，采用Go编程语言进行开发。InfluxDB是一个时间序列数据库，用于优化和处理时间序列数据。时间序列数据最早由Kdb在2000年发布，但随着物联网的兴起，随着NoSQL、NewSQL和大量增长的数据的出现，InfluxDB变得流行起来。

对物联网数据使用InfluxDB的优点包括:

• 允许对序列进行索引
• 它有一个类似sql的查询语言
• 对缺失数据提供内置的线性插值
• 支持数据自动降采样
• 支持连续查询计算聚合

CrateDB

CrateDB: CrateDB是一个分布式SQL数据库管理系统。它是开源的，用Java编写的，包含了来自Facebook Presto、Apache Lucene、Elasticsearch和Netty的组件——因此它是为高可伸缩性而设计的。CrateDB是为使物联网数据工作而设计的。从工业互联网、联网汽车到可穿戴设备，CrateDB是新型物联网解决方案创新者的首选数据库。

将CrateDB用于物联网数据的优点包括:

• 每秒百万个数据点:快速、线性可扩展的数据摄取
• 实时查询:柱状索引和字段缓存提供内存中的SQL性能
• 动态模式:动态添加和查询新的传感器数据结构
• 物联网分析:快速、健壮的时间序列、人工智能、地理空间、文本搜索、连接、聚合
• Always on:内置的数据复制和集群再平衡确保不间断的性能
• ANSI SQL:无锁定，易于任何开发人员使用和集成
• 内置的MQTT代理:直接将设备与数据库集成
• 物联网生态系统:使用Kafka、Grafana、NodeRED等流行的物联网栈软件
• 可以在任何地方运行，以便在边缘或云中进行高效处理

MongoDB

MongoDB: MongoDB是一个免费的、开源的、跨平台的、面向文档的数据库程序。它被归类为一个NoSQL数据库程序。MongoDB使用具有模式的类似json的文档。它是物联网组织的首选，因为它可以让他们存储来自任何上下文的数据，可以实时分析，也可以在他们进行时改变模式。

MongoDB用于物联网数据的优点包括:

• 强大的数据库
• 面向文档的
• 具有一般用途
• 作为一个NoSQL数据库，它使用类似JSON的带有模式的文档

RethinkDB

RethinkDB:在开放源码数据库列表中，RethinkDB位于顶部。它是一个可伸缩的实时Web JSON数据库，是从头开始构建的。RethinkDB通过改变传统数据库架构引入了一种令人兴奋的新访问模型。当开发人员向它发出命令时，它可以不断地将更新后的查询结果实时推送到应用程序。这是一个被开发人员称为change feed的特性。RethinkDB充当数据库、实时存储库和系统状态的消息代理，这是change feed允许的。它的实时推送架构大大减少了构建可伸缩实时应用程序所需的时间和精力。

对物联网传感器数据使用RethinkDB的优点包括:

• RethinkDB有一个可适应的查询语言来检查API，非常容易设置和学习。
• 如果主服务器出现故障，命令会自动转移到新服务器上。
• 节点实时即插即用功能，无需停机一秒，方便添加节点。
• 在Ruby和Tornado中通过Eventmachine提供异步查询，提供异步应用程序编程接口。
• 它提供SSL访问，只是为了通过公共互联网安全访问RethinkDB。
• Floor, ceil和round是RethinkDB提供的各种数学运算符。

SQLite

SQLite数据库引擎是一个进程库，它提供了一个无服务器的(自包含的)事务性SQL数据库引擎。由于其可移植性和较小的内存占用，它对游戏和移动应用程序开发产生了重大影响。

SQLite适用于不需要任何人工支持的设备，因为数据库不需要管理权限。它非常适合用于手机、机顶盒、电视、游戏机、相机、手表、厨房电器、恒温器、汽车、机床、飞机、远程传感器、无人机、医疗设备和机器人，以及物联网。

客户端/服务器数据库引擎被设计为驻留在网络核心的数据中心内。SQLite也在那里工作，但SQLite也在网络的边缘蓬勃发展，在为自己提供快速可靠的数据服务的同时，为那些连接不可靠的应用程序提供服务。

对物联网数据使用SQLite的优点包括:

• 内存占用小
• 它是真实的
• 使用前无需设置
• 没有依赖性

Cassandra

Apache Cassandra: Apache Cassandra是一个免费的开源分布式NoSQL数据库管理系统，最初发布于2008年。它旨在通过许多商用服务器处理大量数据，提供没有单点故障的高可用性。

在物联网中，由于连接的设备数量巨大，通过各种网络产生、跟踪和共享数据的规模非常大。Cassandra非常擅长利用大量的时间序列数据，这些数据直接来自于设备、用户、传感器以及存在于不同地理位置的类似机制。

在物联网中使用Apache Cassandra的优点

数据包括:

• 容错
• 展示了高性能
• 去中心化:集群中的每个节点都是相同的
• 可伸缩
• 持久性
• 确保可控:每次更新都可以选择同步复制和异步复制
• 弹性:读写都是实时执行的，任何应用都不存在停机
• 专业支持:加强第三方提供的合同和服务。

 

原文：https://www.opensourceforu.com/2018/05/open-source-databases-that-work-best-for-iot/

本文：http://jiagoushi.pro/node/1331

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

整体架构

IoT设备组件

硬件抽象层

为了确保便携性，IoT设备需要包括一个软件层，可以访问MCU的硬件功能，如闪存，GPIO，串行接口等。

提供高级API用于访问由微控制器（如GPIO，ADC，MEMS等）提供的硬件功能。它可以直接连接到由硅供应商提供的本地库，驱动程序和板支持包。

通讯

IoT设备需要允许将其连接到有线或无线协议的驱动程序和协议，从而实现通信。

提供MQTT协议的实现。

远程管理

IoT设备需要远程控制的情况很多，例如升级固件或监控其电池电量。

• Provides an implementation of the OMA LWM2M standard.

• 提供OMA LWM2M标准的实现。

IoT网关组件

操作系统

Linux (Ubuntu/Ubuntu Core, Yocto-based linux distribution), Windows.

应用容器或者应用运行时

OSGi Runtime

通讯和连接

与网关I / O（例如串行，RS-485，BLE，GPIO等）接口，并支持可用于连接设备（例如MODBUS，CAN总线等）的许多现场协议。

网络管理

通过广泛的接口（蜂窝，Wi-Fi，以太网等）提供先进的网络和路由功能。

数据管理和消息

实现基于本地MQTT的消息传递解决方案，允许在网关上运行的应用程序透明地与云平台通信，而无需处理网络接口的可用性，或如何表示IoT数据。 通过内置的Apache Camel消息路由引擎可以获得对附加消息协议的支持。

I

远程管理和消息

提供基于MQTT协议的远程管理解决方案，除了控制（安装，更新，修改设置）其运行的软件之外，还可以监视IoT网关的总体运行状况。

云平台组件

连接性和消息路由

IoT平台需要能够与使用不同协议和数据格式的大量设备和网关进行交互，然后将其规范化，以便轻松集成到企业的其余部分

提供用于与使用任意协议的设备交互的统一API，以及可扩展的框架来添加其他协议。

提供MQTT代理的实现。

设备管理

IoT平台应该能够配置新的软件更新和管理设备。

提供OMA LWM2M设备管理协议的实现

设备注册

中心注册表有助于识别和验证在IoT解决方案中运行的设备/网关

提供管理工具，向设备和网关推出软件更新

事件管理

•  

分析

• 包括Apache Hadoop，Apache Spark和Apache Storm。

• 提供对仪表板和存储在各种数据存储库中的数据报告的支持。

应用服务接口

通过公开应用程序编程接口（API），能够整合和分析数据，并创建报告，图表和仪表板。

• 有助于公开一致的API，用于消费遥测数据或向设备发送命令，以便使IoT应用程序开发合理化。

开放标准

CoAP

CoAP（约束应用协议）是专门用于受限节点和网络的协议。

它实现了REST架构风格，可以透明地映射到HTTP。 然而，CoAP还提供超出HTTP的功能，如本地推送通知和群组通信。

DTLS

数据报传输层安全（DTLS）协议为诸如数据报协议提供了通信安全性。 DTLS允许基于数据报的应用程序以旨在防止窃听，篡改或消息伪造的方式进行通信。 对于IoT应用，DTLS可用于保护基于CoAP的通信。

ISO/IEC 15118

题为“道路车辆 - 车辆到电网通信接口”的国际标准ISO / IEC 15118定义了电动汽车（EV）和充电站（称为电动车辆供应设备 - EVSE）之间的数字IP通信接口。

它允许基于在EV和EVSE之间交换的广泛信息的用户友好的“插入和充电”机制进行认证，授权，计费和灵活的负载控制。

IEC 61499

国际标准IEC 61499，涉及工业过程测量和控制系统功能块的主题。 IEC 61499的规范定义了分布式控制系统的通用模型，并基于IEC 61131标准。

OMA LightweightM2M (LWM2M)

OMA轻量级M2M（LWM2M）是M2M / IoT设备设备管理的行业标准。 它依赖于CoAP，因此针对传感器或蜂窝网络的通信进行了优化。

OMA LWM2M提供了一种可扩展的对象模型，允许除了核心设备管理功能（固件升级，连接监控，...）之外，还可以实现应用程序数据交换

MQTT

MQTT是一种用于连接物理世界设备和网络以及IT和Web开发中使用的应用程序和中间件的协议，使其成为IoT和M2M的理想连接协议。

它是一种轻量级的发布订阅协议，可在嵌入式设备和移动平台上运行，同时通过有线和无线网络连接到高度可扩展的企业和Web服务器。对于需要较小代码占用和/或网络带宽或连接不可预测的远程嵌入式系统以及需要较小尺寸，低功耗，最小化数据包和高效分配的移动应用程序，该连接非常有用的信息到一个或多个接收器。

通过松散耦合和服务质量，MQTT针对动态系统环境进行了优化，其中需要向Web和企业服务器以及其他消费者提供大量物理世界消息和事件。 MQTT已经很好地满足了M2M和IoT应用的意想不到的需求。

SensorThings API

SensorThings API是一个开放的地理空间联盟（OGC）标准，为通过网络互连IoT传感设备，数据和应用提供了一个开放和统一的框架。 这是一个开放的标准，涉及物联网的语法互操作性和语义互操作性。

oneM2M

oneM2M规格提供横向框架，以支持智能城市，智能电网，连接车，家庭自动化，公共安全和健康等广泛的应用和服务。

OPC Unified Architecture (UA)

OPC统一架构（UA）是一种互操作性标准，可实现安全可靠的工业自动化数据交换，同时保持跨平台和供应商的中立。 该规范由OPC基金会在个别软件开发商，行业供应商和最终用户的指导下开发和维护。 它定义了客户端和服务器之间的接口，包括访问实时数据，监控报警和事件，历史数据访问和数据建模

PPMP

PPMP（生产绩效管理协议）指定了一种允许捕获生产设备性能分析所需的数据的格式。 它允许监视后端在生产过程的上下文中收集和评估机器的关键指标。 它正在通过允许将机器状态与当前生产的部件相关联来实现。

用于传感器分析的KSQL UDF。利用KSQL的新的API特性，用Java轻松地构建UDF / UDAF函数，从而使用Apache Kafka进行连续流处理。用例:联网汽车——使用深度学习的实时流媒体分析。

我为混合机器学习基础设施构建了一个场景，利用Apache Kafka作为可伸缩的中枢神经系统。使用公共云在极端尺度下训练分析模型(如通过谷歌ML引擎在谷歌云平台(GCP)上使用TensorFlow和TPUs。预测(即模型推断)是在本地Kafka基础设施的边缘前提下执行的(例如利用Kafka流或KSQL进行流分析)。

这篇文章的重点是在前提部署。我用KSQL UDF创建了一个用于传感器分析的Github项目。它利用KSQL的新API特性轻松地使用Java构建UDF / UDAF函数，对传入事件进行连续流处理。

用例:联网汽车——使用深度学习的实时流媒体分析

连续处理来自连接设备(本例中的汽车传感器)的数百万个事件:

我建立了不同的分析模型。他们在公共云上接受训练，利用TensorFlow、H2O和谷歌ML引擎。模型创建不是这个示例的重点。最终的模型已经准备好投入生产，并可以部署进行实时预测。

模型服务可以通过模型服务器或原生嵌入到流处理应用程序中来完成。查看模型部署中RPC与流处理的权衡和“TensorFlow + gRPC + Kafka流”示例。

演示:使用MQTT、Kafka和KSQL在边缘进行模型推断

Github项目生成汽车传感器数据，通过Confluent MQTT代理将其转发到Kafka集群进行KSQL处理和实时分析。

这个项目主要是通过MQTT将数据输入Kafka，通过KSQL对数据进行处理:

Confluent MQTT代理的一大优点是可以简单地实现物联网场景，而不需要MQTT代理。您可以通过MQTT代理直接将消息从MQTT设备转发到Kafka。这大大减少了工作和成本。如果您“只是”希望在Kafka和MQTT设备之间进行通信，那么这是一个完美的解决方案。

如果你想看这个故事的其他部分(与像Elasticsearch / Grafana这样的sink应用的集成)，请看看Github项目“KSQL流物联网数据”。通过Kafka Connect和Elastic connector实现了与ElasticSearch和Grafana的集成。

 KSQL UDF 源代码

开发udf非常容易。只需在一个UDF类中实现一个Java方法:

 

@Udf(description = "apply analytic model to sensor input")
public String anomaly(String sensorinput){ "YOUR LOGIC" }

 

下面是KSQL UDF异常检测的完整源代码。（Anomaly Detection KSQL UDF.）

如何运行与Apache Kafka和MQTT代理演示?

在Github项目中描述了执行演示的所有步骤。

您只需要安装Confluent Platform，然后按照以下步骤部署UDF、创建MQTT事件并通过利用分析模型的KSQL处理它们。

我使用mosquito to生成MQTT消息。当然，您也可以使用任何其他MQTT客户机。这就是开放和标准化协议的最大好处。

Apache Kafka和机器学习的混合云架构

如果你想了解一个可扩展的、不确定供应商的机器学习基础设施背后的更多概念，请看看我在Slideshare上的演示，或者观看相应的Confluent网络研讨会“释放Apache Kafka和TensorFlow在云端”的记录。

 

原文：https://www.kai-waehner.de/blog/2018/08/02/deep-learning-kafka-ksql-udf-anomaly-detection-mqtt-iot-sensor/

本文：http://jiagoushi.pro/node/1100

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

随着有价值的用例的出现，物联网(IoT)正得到越来越多的关注。然而，一个关键的挑战是整合设备和机器来实时和大规模地处理数据。Apache Kafka®及其周边的生态系统，包括Kafka Connect、Kafka Streams和ksqlDB，已经成为集成和处理这类数据集的首选技术。

在Kafka客户端api(如Java、Python、.NET和C/ c++)之外，需要注意的是:

• Kafka连接源和接收连接器，它们在两个方向上与MQTT代理集成
• 汇合式MQTT代理，它从物联网设备中摄取数据，而不需要MQTT代理
• Confluent REST代理用于简单但功能强大的基于http的集成

在我更详细地讨论这些问题之前，让我们先看一看目前在物联网项目中使用Confluent Platform和Confluent Cloud的一些常见用例。

物联网技术和事件流平台的用例

Confluent Platform和Confluent Cloud已经被用于许多物联网部署，包括消费者物联网和工业物联网(IIoT)。大多数场景都需要可靠、可伸缩和安全的端到端集成，从而支持实时的双向通信和数据处理。一些具体的用例是:

联网的汽车基础设施:

汽车彼此和远程数据中心或云进行通信，以执行实时交通建议、预测维护或个性化服务。

例如:Audi

智能城市和智能家居:

建筑、交通灯、停车场等很多东西都相互连接，以实现更高的效率，提供更舒适的生活方式。能源供应商将房屋连接起来，买卖自己的太阳能，并提供额外的数字服务。

例如:E.ON

智能零售和客户360:

客户的移动应用程序与CRMs、忠诚度系统、地理位置和天气信息等后端服务之间的实时集成，创建了特定上下文的客户视图，并允许更好的交叉销售、促销和其他面向客户的服务。

例如: Target

智能制造:

工业企业将机器和机器人集成在一起，优化业务流程，降低成本，比如提前报废零部件，或者提前进行预防性维护，在机器部件损坏之前更换它们。数字服务和订阅服务提供给客户，而不仅仅是向他们销售产品。

例如:Severstal

在这些用例中，机器学习发挥了巨大的作用，无论行业是什么，您可以使用Apache Kafka阅读来推动尖端的机器学习，以获得更多的见解。

现在让我们来看看一个健壮的物联网集成架构。

端到端企业集成架构

物联网集成架构需要将edge(设备、机器、汽车等)与数据中心(on-premises、cloud和hybrid上)集成，以便能够处理物联网数据。

物联网集成架构的要求和挑战

为了灵活和面向未来，物联网集成架构应该具备以下要求:

• 可伸缩的数据移动和处理:处理反向压力，可以处理不断增加的吞吐量
• 敏捷开发和松耦合:不同的源和汇应该是各自的解耦域。不同的团队可以开发、维护和更改对设备和机器的集成，而不依赖于处理和分析数据的其他源或sink系统。微服务、Apache Kafka和域驱动设计(DDD)更详细地介绍了这一点。
• 创新开发:根据特定用例的灵活性和需求，可以使用新的和不同的技术和概念。例如，一个应用程序可能已经将数据发送到MQTT代理，以便您可以从那里消费，而另一个项目根本不使用MQTT代理，您只是想直接将数据推入事件流平台以进行进一步处理。

但是几个挑战增加了物联网集成架构的复杂性:

• 复杂的基础设施和操作通常无法更改——尽管需要与现有的机器集成，但您无法轻松地向机器本身添加代码
• 与许多不同的技术集成，比如MQTT或OPC统一架构(OPC Unified Architecture, OPC UA)，同时也遵守遗留的和专有的标准
• 由于不良的物联网网络导致通信不稳定，导致成本和投资在边缘

考虑到这些需求和挑战，现在让我们看看MQTT和其他IoT标准如何帮助集成数据中心和edge。

物联网标准和技术:MQTT, OPC UA，西门子S7, PROFINET

市场上有许多物联网标准和技术。如果必须选择，以下是实现物联网集成的最常见选项:

• 专有接口:特别是在工业物联网(IIoT)中，这是最常见的场景。计算机以专有格式提供大量通常是封闭的和不兼容的协议。例如S7、PROFINET、Modbus或自动分派系统(ADS)。监控控制和数据采集(SCADA)通常用于控制和监控这些系统。
• OPC UA:这是一个开放的、跨平台的、用于工业自动化的机器对机器通信协议。每个设备都必须进行改造，使其能够使用新的协议，并使用一个公共客户机与这些设备进行通信。要启用OPC UA，许可证成本和现有硬件的修改是必需的。
• PLC4X:作为一个Apache框架，它通过实现驱动程序(类似于用于关系数据库的JDBC)来提供一个统一的API，这些驱动程序用于与大多数工业控制器以其本身理解的协议进行通信。不需要许可证成本或硬件修改。
• MQTT:它构建在TCP/IP之上，用于受限制的设备和不可靠的网络，应用于许多(开放源码)代理实现和许多客户机库。它包含用于不良网络/连接的IoT特定特性，并被广泛使用(主要用于物联网，但也通过MQTT通过WebSockets用于web和移动应用程序)。

难怪这两个领域的技术诀窍分布不均。例如，在物联网环境中，近年来发展了大量的数据交换协议。只有MQTT对自动化技术员工来说是熟悉的。

用同样的方法，工业协议对软件工程师来说是一本有七个封条的书。可能有些工业协议非常适合特定的物联网解决方案，就像现代物联网协议的某些安全特性适合工业一样。但这并不能改变什么。

MQTT已经成为当今大多数物联网场景的标准解决方案，特别是在IIoT之外。尽管MQTT是这篇博客文章的重点，但在以后的文章中，我将通过利用PLC4X及其Kafka集成，讨论MQTT与IIoT及其专有协议(如西门子S7、Modbus和ADS)的集成。有关在IIoT集成场景中使用Kafka Connect和PLC4X的更多细节，您可以查看这些关于自动化行业中灵活和可伸缩集成的幻灯片(flexible and scalable integration in the automation industry)，以及解释IIoT、Apache Kafka和PLC4X之间关系的视频(video explaining the relation between IIoT, Apache Kafka, and PLC4X)。

根据我与工业客户(他们对封闭的、不灵活的接口的挑战感到痛苦)的交谈，我注意到越来越多的IIoT设备和机器也提供了可以集成到现代系统中的MQTT接口。

关于MQTT的权衡，考虑利弊:

优点

• 广泛采用
• 轻量级
• 有一个简单的API
• 为连接差和延迟高的场景而构建
• 支持许多客户机连接(每个MQTT服务器数万个)

缺点

• 只是排队，而不是流处理
• 无法处理使用量激增(没有缓冲)
• 大多数MQTT代理不支持高可伸缩性
• 异步处理(通常脱机很长时间)
• 缺乏与企业其他部分的良好集成
• 单一基础设施(通常位于边缘)
• 不能对事件进行再处理

这些权衡表明MQTT是为物联网场景构建的，但是在集成到公司的企业架构时需要帮助。这就是事件流媒体平台Apache Kafka及其生态系统发挥作用的地方。

Apache Kafka作为一个事件流平台

Apache Kafka是一个事件流平台，它结合消息传递、存储和数据处理来构建高度可伸缩、可靠、安全和实时的基础设施。那些使用Kafka的人经常使用Kafka连接以及使集成与任何源或接收器。Kafka流也很有用，因为它允许连续的流处理。从物联网的角度来看，Kafka提出了以下折衷方案:

优点

• 流处理，不仅仅是排队
• 高吞吐量
• 大规模的
• 高可用性
• 长期存储和缓冲
• 再处理的事件
• 与企业的其他部分良好集成
• 混合、多云和全球部署

缺点

• 不是为成千上万的连接而建的
• 需要稳定的网络和坚实的基础设施
• 缺乏信息技术特有的特征，比如“活着”和“遗嘱”
• 由于Kafka不是为边缘物联网通信而构建的，因此Apache Kafka和MQTT的结合是构建可伸缩、可靠和安全的物联网基础设施的天成之选。

如何将两者结合起来?

下面几节将演示三种kafka本地选项，这意味着除了MQTT设备/网关/代理和Confluent平台之外，您通常不需要其他技术来集成和处理IoT数据。

Confluent MQTT连接器(源和汇)

Kafka Connect是一个包含在Apache Kafka中的框架，它集成了Kafka与其他系统。其目的是在充分利用Apache Kafka的所有特性(例如高吞吐量、可伸缩性和可靠性)的同时，轻松地向可伸缩和安全的事件流管道添加新系统。下载和安装新的源和接收器连接器的最简单方法是通过Confluent Hub。您可以找到安装步骤、文档，甚至是开放源码的连接器的源代码。

Kafka Connect MQTT连接器是用于从MQTT代理发送和接收数据的插件。

MQTT代理是持久的，并提供MQTT特定的特性。它消耗来自物联网设备的推送数据，Kafka Connect以自己的速度拉这些数据，而不是压倒源或被源压倒。开箱即用的可扩展性和集成特性，如Kafka连接转换器和单消息转换(SMTs)，是使用Kafka连接连接器的进一步优势。

MQTT连接器独立于特定的MQTT代理实现。我曾见过几个项目在从试验项目到预生产的过渡过程中从使用mosquito to开始，然后转向可靠的、可伸缩的代理，如HiveMQ。

用于在没有MQTT  Broker的情况下摄入数据的MQTT  Proxy

在某些情况下，主要的挑战和需求是摄入数据到Kafka，以便在其他后端系统中进行进一步的处理和分析。在这种情况下，MQTT代理只是增加了复杂性、成本和操作开销。

Confluent MQTT代理交付了一个kafka本地的MQTT代理，该代理允许组织消除中间MQTT代理的额外成本和延迟。MQTT代理访问、组合和保证物联网数据流到业务中，而不增加额外的复杂性层。

MQTT代理是水平可伸缩的，从物联网设备使用推送数据，并以低延迟将其转发给Kafka代理。不需要MQTT代理作为中介。Kafka经纪人是负责物联网数据持久性、高可用性和可靠性的真相来源。

然而，尽管在集成物联网设备时，每个人都考虑诸如MQTT或OPC UA之类的物联网标准，但REST和HTTP往往是更简单的解决方案。

REST代理作为物联网集成的“简单”选项

REST Proxy为Kafka集群提供了一个RESTful接口，使其可以轻松地生成和使用消息、查看集群的状态以及执行管理操作，而无需使用本机Kafka协议或客户机。

为什么要使用HTTP(S)进行物联网集成?由于各种原因，与特定于iot的技术相比，REST Proxy使实现和部署更简单、更快、更容易:

• 它简单易懂
• HTTP代理是基于推的
• 从组织和治理的角度来看，安全性更容易——问问您的安全团队吧!
• 可伸缩性与标准负载均衡器，尽管它仍然是同步HTTP，这不是高可伸缩性的理想
• 支持数以千计的消息每秒

无论您决定如何集成物联网设备，构建可靠的端到端监控基础设施都是必不可少的。

端到端监控和安全性

分布式系统很难监控和安全。Kafka集群没有太大的不同——您必须监视和保护Kafka代理、ZooKeeper节点、客户端消费者组(Java、Python、Go、REST等)以及Connect和ksqlDB集群。

就端到端监控您的整个Kafka基础设施而言，Confluent Control Center提供了对Kafka集群内部工作和流经它们的数据的洞察。Control Center通过精心策划的仪表板为管理员提供监视和管理功能，以便他们能够提供最佳性能并满足集群的sla。这包括:

• 从生产者到代理到消费者的端到端监控
• 连接集群(源和接收)的管理，无论它是中心基础设施还是体系结构中是否有域驱动的组件
• 用于安全通信和确保遵从性的基于角色的访问控制(RBAC)
• 对可用性、延迟、消耗、数据丢失等进行监视和警报。

通过使用诸如基于角色的访问控制(RBAC)这样的安全特性，您还可以为Confluent平台的所有组件启用简单的、标准化的身份验证和授权。

为您的物联网集成挑战选择正确的组件

物联网集成场景的用例总是类似的:与设备或机器集成;将事件流数据实时输入Kafka集群(在场所或云中);使用Kafka流和ksqlDB处理数据;然后将数据发送回设备或机器，和/或其他接收器，如数据库，分析工具，或任何其他业务应用程序。

通过使用诸如客户机、MQTT连接器、MQTT代理或REST代理等kafka本地选项，您可以集成物联网技术和接口来建立一个强大但简单的体系结构，而不需要使用其他工具。这在24/7任务关键型部署中特别推荐，因为每增加一个组件都会增加复杂性、风险和成本。你有很多选择，所以选择一个最适合你的情况。

如果你想读一个完整的故事建立一个端到端物联网体系结构从边缘到云,读启用连接转换与Apache卡夫卡和TensorFlow在谷歌的云平台,专注于谷歌的云平台,融合性的云,MQTT集成构建一个可伸缩的、可靠的机器学习的基础设施。

 

这篇博客文章的内容也被记录在名为“端到端集成:物联网边缘融合云”的交互式灯板记录中。

 

原文：https://www.confluent.io/blog/iot-with-kafka-connect-mqtt-and-rest-proxy/

本文：http://jiagoushi.pro/node/1103

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】