英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料
物联网管理器:智能城市的开源物联网框架
摘要：
最近关于物联网的调查证实全世界有200亿台联网设备和计算机，而且数量还在增加。我们帮助物联网和云计算范式的融合，传感器到处都在部署网络，网络的数量和重要性都在增加。主要问题之一是通过这些传感器收集为社区提供能够存储和重新安排数据的通用且有弹性的框架。然而，世界上最大的信息技术公司倾向于发布产品作为一种服务方式，避免透露有关设计和实现细节的专门知识。作为一个结果，学术机构普遍倾向于将这些主流物联网平台用作“黑匣子”。在本文中，我们讨论了一些最常用的物联网平台，并介绍了物联网管理器为传感器网络管理而设计的框架，完全是在剑桥大学内部开发的博洛尼亚。通过这个案例研究，我们为科学界提供了一个详细的实施策略关于我们具体的物联网解决方案。我们的结果得到了物联网管理器客户端的LGPL版本的支持作为研究和教学的试验台。
- 介绍
物联网(IoT)现在是我们日常生活的一个统一现实生活:从汽车到健身传感器，从空调系统到相机，越来越多的设备可以互相传输数据[1]。这个愿景可以从国内域名打城市规模和地区脚本，传感器网络已成为一个共同的特征[2-4].采用这种方法的好处技术是清晰的，但是传感器网络的持续扩展已经生成各种不一致的环境。一方面，这种情况带来了几种安全威胁[5,6]，另一方面，不相关传感器网络的集成可以是任何事情，但是是简单的[7]。我们可以想象这些传感器网络作为一个谜题:在某些情况下他们的集成将会微不足道而有时可能非常复杂。假如我们想用一个在敏捷方法单一的紧凑的解决方案通过不同的体系结构可以产生数据。例如，想象一下集成数据设备来源于桑坦德银行网络，数据产生通过新的芝加哥的一系列事情和那些智能市民平台。在这种情况下，我们将不可避免地面临许多问题，包括由于网络节点的性质不同，采用的技术和架构也不同。传感器网络的例子提供了多种传感器，以及不共享的通信和存储协议。一个被广泛采用的清晰的设计方法缺席的情况下也使这个任务相当困难。带着这一原则，一些专业已经发布了满足上述需求的物联网平台。大多数这些解决方案以一种随时可用的方式提供缺乏透明性，提供的技术信息有限，以及高级架构和通用通信流[8]。通用的通信流这显然是就商业模式而言，这是可以理解的：这是不合理的为一个专业揭示相关的技术细节和设计选择采用。因此，使用这样的平台意味着依赖于黑盒。本文的目的是探讨其中一些最为重要的问题承诺IoT平台而提出一个完全自制方案依靠开源技术。这种方法允许我们建立在平台上讨论堆栈的每一层的设计和实现细节，使研究人员和从业者充分了解物联网解决方案背后的原因。其他学术机构觉得有必要提出IoT平台，可以提供一个观察下的意见。例如Castellani等人[9]提出了一个专注于室内环境的解决方案。相反的我们的建议主要是设计户外环境和特定的传感器网络分布于市区及郊区。因此，特别的重点将放在不同网络之间的集成和互操作性上。在这种情况下，我们想提供从各种传感器目前情况来看可能监控的信息(see.Section 3.1）如所提议的[10,11]，我们想提供一个IoT有用的实验教学和研究活动。首先，我们想要提出一个市民行动的平台作为活动组件，例如将一个或多个节点添加到以敏捷的方式建立的网络[12]，或通过专用的客户端应用程序监视感兴趣的特定领域。
2.物联网平台比较
自从IoT这个术语是在1999年由Kevin Ashton期间在宝洁公司介绍，IoT解决案背后的基本思想广泛地探讨了学术界和ICT社区。物联网领域可以直观地讨论如：考虑一些分布式传感器或小工具(即“东西”)放在在一个不可预测的广阔环境中(房子，大城市或一个更大的地区)。这些东西能够收集大量的将原始数据转化为相关信息。通常,这生态系统会主动做出反应，最小化(或至少试图最小化)人类的介入。
尽管简单来说这个场景可能出现，隐藏的这些开放的问题应该采用哪种架构?哪些需求是最有意义的？哪一个应采用通信标准以使设备能够使工作有互操作性？哪种API应该轻松的实现允许传感器(或者整个传感器网络)加入生态系统？在[14]中，作者提出了一个有趣的比较突出几个物联网平台和推断参考体系结构。相反，一个物联网平台在讨论在主要的需求中的全面的描述和比较(包括IoT平台的功能和无功能的)[15]。
物联网领域提出了许多平台和解决方案。它们中的每一个都在设计时考虑了业务模型，因此保持特定的特点:在这项工作中，我们采用的分类法提出[16]，其中物联网平台讨论了相应的关系应用领域。
设备管理平台被定义的开放的移动联合设备管理，必须保证供应和在移动的设备,包括远程参数化和同时配置。同样，它们应该允许远程固件更新以及对设备故障和错误的实时监控[17]。因此，这些平台能够快速部署个人的或整个组设备，并允许在他们之上定义分类法和阶层。它们还允许定义不同的访问策略类型的设备。这类解决方案的一个关键方面是趋向于强调是网络资源的优化。设备管理平台正变得越来越重要，并因此而被削弱许多公司的注意力，如亚马逊，在2017年底发布了新的亚马逊物联网设备管理平台[18]。
应用程序开发平台旨在紧固实现ICT服务解决IoT领域的过程。最终用户的应用程序是通过自动代码生成和开发的，与一些预定义的API相结合。最著名的工具包是Temboo[19],允许参数化，事件管理和自动代码生成的异类设备。
顾名思义，应用程序支持平台是允许的物联网架构与现有的外部服务和
应用程序。因此，这些解决方案在硬件之间进行操作由传感器和执行器以及终端用户应用程序组成的层层。他们经常作为一个集成中间设备:设备通讯直接与平台通过传输协议等HTTP/S或MQTT，并使用经典数据交换封装数据格式(XML、JSON)。这些集成中间件重新排列这信息,并将其给到最终用户应用程序。
我们在下面讨论的解决方案属于后一类。为了便于阅读，我们指出了应用程序支持平台，通常被称为物联网中间件、中间件或物联网中间件:我们可以交换使用这些定义。在介绍之前平台在我们的解决方案中，我们将讨论属于后一类的一些最突出的平台。
2.1.AWS物联网核心
亚马逊网络服务物联网核心是被亚马逊提议为中间设备。它包含依赖于平台的云解决方案即服务(PaaS)业务模型。可伸缩性和互操作性是此解决方案最相关的特性是:亚马逊确保单个物联网核心实例可以支持数十亿台设备，允许进行交换AWS端点之间的数百亿条消息的主要作用。因此，AWS的物联网核心是提供之间可靠的连接“事情”和AWS云。为了做到这一点，大家都很熟悉HTTP,MQTT和使用WebSockets协议通讯担保通过TLS X.509证书。
这个平台架构由四个主要模块(信息处理,设备，规则引擎,安全和统一)加上没有表示的第五个组件(设备网关)。后一个模块将设备连接到消息代理。特别的,它使传入接口实现上述的协议和消息代理充当中介。信息代理是一个允许所有设备的发布/订阅服务接收或发送消息相关的特定主题他们以前注册(e.g.传感器/湿度/起居室).A设备通讯在自己的状态下平台发布消息合适的话题。这个设备影子服务在云中启用虚拟化和持续化，允许每个设备维护已知设备状态，即使它不再在线。当一个对象是适当连接，其影子的状态可以关于物理设备不断更新。相反的，当通讯失败，仍有可能与设备交互的依赖它的影子。这个规则引擎模块工具的业务逻辑平台，使收集和处理原始数据成为可能。正如它的名字所说,允许用户定义规则,协调这些关于其他的项目或者AWS设备的分布的消息。最终，这些组件与安全与身份模块交互负责提供对等的身份验证和加密堆栈的所有通信级别。因此,一个双向的通信在没有身份验证的情况下是永远不会出现的。亚马逊网络服务提供了这个中间设备的所有的利益，但是，可以预测的是，一些细节还是未知的。
2.2.微软Azure物联网套件
Azure物联网套件[21]是微软开发的云平台。AWS物联网核心的商业模式是PaaS（平台即服务）。主要的这个平台提供的优点是用户安装预配置解决方案设计的能力以适应常见IoT情形。这些解决方案被免费发布。例如，Azure IoT套件与天气预报设置，使数据收集，以及信息传递到中间件及其分析Azure机器学习模块。每个预先配置的解决方案涉及到不同的设备,依靠几个模块其中提供作为服务Azure和Azure IoT中心,这确实是真实的中间设备。Fig.2显示的参考架构IoT系统根据微软的愿景:蓝色矩形内的代表支持物联网解决方案所需的云组件集合。Azure物联网中心作为云网关技术的引领者。
图1核心建筑详细信息
图2 微软物联网参考体系结构
Azure物联网中心支持数百万设备之间的连接基于云的后端，支持双向通信
AMQP、MQTT和HTTPS协议。这个中心的特点包括双设备，类似于AWS设备影子的解决方案。A双设备由被存储涉及的状态信息配对的设备中的JSON文档组成。对于每个连接的设备，Azure维护这些设备，它们的信息可以被设备本身或其他设备使用应用程序，以便执行设备配置或查询数据。该特性对批处理操作非常有帮助。关于通信安全，Azure Hub IoT每个中心授权访问端点通过一个基于符号的授权机制或通过X.509证实。这种授权可能会限制对中心和某些中心的访问特定的功能。
2.3.SiteWhere
SiteWhere[22]不同于以前讨论的中间件设备来，首先它是一个业务模块。它确实是一个开源的物联网平台，由SiteWhere开发和维护。这个解决方案是在CPAL-1.0(公共属性许可1.0版)。更确信的是,这个平台的两个变体已经发布:免费使用社区版本和企业版本,由在一个扩展第一个付费版本。后一种解决方案需要直接从SiteWhere购买。几个人是要求部署实际案例:一个Apache Tomcat应该配置为web服务器以及MongoDB存储库。Java和HiveMQ(一个MQTT代理)
也需要。
图3建筑的位置
SiteWhere服务器表示它所在的中心节点允许同时管理组件和复位服务。这个解决方案是设计为一个多租户系统，其中租户负责大部分的处理逻辑。在每个服务之内，一个或多个租户需要靠自己，每个作为不同IoT运行这个应用。要求它们将这些信息保持分开，每个租户的信息加上自己的数据存储。如图3所示，每个租户还具有一个处理功能可以在不影响其他管道的情况下自定义的管道。传感器通过租户和设备之间的网关发送数据JSON文档组成..SiteWhere支持MQTT、AMQP和REST通信。
2.4.三星SmartThings
SmartThings[23]是一个物联网应用生态系统。SmartThings该项目于2012年通过启动器众筹活动启动。基本思想是通过集线器连接到一组“事物”(如温湿度传感器、烟雾和一氧化碳报警器)实现智能家居环境的解决方案。当项目开始时，它是耦合的一个智能手机应用程序能够与远程集线器通信。2014这是SmartThings被三星电子收购后的一个里程碑。最初的体系结构已经有了相当大的发展成为一个真正以云为中心的平台。确实如此，如图4所示，即使没有直接的集线器连接的帮助，现在可以用三种不同的策略将设备连接到云后端。另一种类型的连接是云连接，这使得有可能实现(基于云的)第三方设备和SmartThings云之间的间接通信通道。而作为设备和云之间的网关的枢纽的优势是建议，几个操作可以在本地执行，而不需要需要查询后端。在这个特定的例子中，SmartThings指的是这些设备是中心连接的，它们依赖于ZigBee或Z-Wave
通信协议。在SmartThings应用程序中，对象通常是根据它们所在的房间进行组织和分组的。因此，概念是SmartThings客户端的一个关键方面。
SmartThings包含了自动化的概念，用户无需任何人工干预即可与生态系统进行交互。关于自动化，有两个可能采用的策略：第一个依赖于WebHook，第二个依赖于AWS Lambda函数。在这种情况下，有可能定义一种旨在调整的自动化策略特定房间内的光强度根据天气变化而变化。这个云解决方案还支持通过SSL/TLS协议[24]在所有连接的组件之间进行加密通信。虽然SmartThings提供的架构是针对的家庭环境，或者更普遍地说，智能建筑的概念，它的特点使它有可能在更广泛的背景下被采用。特别是，由于有了云连接，我们可以实现联网一个传感器网络。
3.物联网管理
在[25]中，Calderoni等人提出了一个在城市环境中管理多个子系统通用的ICT架构设计。物联网管理代表对该模型进行了改进，实现了其主要特点。在这篇文章中，我们想要清楚地解释我们的平台是如何设计实现的，以向科学界和实践工作者提供一个完全开放物联网堆栈的切实例子。在此之前，物联网玩家并不经常透露有关的细节其解决方案。除此之外，越来越常见的情况是，关于连接的详细信息并不支持底台表单的传感器。讨论通常集中在物联网中间件层，它的基础设施和提供的服务。然而，这导致了忽视一些相关的细节，一方面是与中间件通信的物理组件，另一方面是与中间件通信的物理组件提交可能的应用程序组件。在这一部分我们要面对整体讨论:通过自顶向下的方法，我们将不仅讨论集成中间件的作用，还将讨论物联网管理器，还描述了堆栈的物理层和应用程序层。事实上，这将允许我们描述在我们
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[245992]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
