Azure IoT 解决方案(面向水务行业)






3.86/5 (11投票s)
本文展示了如何为水务行业构建 Azure IoT 解决方案。
引言
本文展示了如何为水务公司构建 Azure IoT 解决方案
该解决方案因其能够使用各种 Azure 服务分析、存储和报告 50 万个仪表和每年 2.5 亿笔交易的数据,而获得了微软的认可。开发 Microsoft Azure IoT 解决方案大大降低了公用事业行业的此类解决方案的成本。它还能够扩展到数万亿次仪表读数。我们已接受微软采访,将发布关于此解决方案的案例研究。
此解决方案也曾被加利福尼亚州的一家新闻频道报道。您可以在此处观看新闻: http://www.nbclosangeles.com/video/?anchor_tag=%21%2Fon-air%2Fas-seen-on%2FSmart-Meters-Help-Long-Beach-Crack-Down-on-Water-Wasters%2F298093051&anchor_tag=%21%2Fon-air%2Fas-seen-on%2FSmart-Meters-Help-Long-Beach-Crack-Down-on-Water-Wasters%2F298093051#!/on-air/as-seen-on/Drought-Fighting-/298093051
由于 Azure 提供了一个集成的开发环境,可以随时访问服务器、网络、软件和开发工具,因此开发时间减少了约 50%。这是一个惊人的加速。
目录
使用的物联网组件
此解决方案中使用的物联网组件是
- 公用事业仪表:仪表是基于 CDMA 的无线设备,通过互联网连接到 Azure 服务。它在安装在设备内存中的嵌入式代码上运行。
- Azure 云服务: Microsoft Azure 提供的 PaaS 产品,用于托管您的 Web 应用程序。它用于创建高可用性和无限可扩展的应用程序。部署应用程序后,Azure 会处理其余部分。从预配到负载平衡,再到健康状况监控。您的应用程序享有业界领先的 99.95% 每月 SLA。
- Azure 机器学习: Azure 机器学习服务是一种强大的基于云的预测分析服务,可以快速创建分析解决方案。它是一项完全托管的服务。
- 服务总线队列: 服务总线队列支持代理消息传递通信模型。消息生产者(发送方)将消息交给队列,然后继续其处理。异步地,消息消费者(接收方)从队列中拉取消息并处理它。队列提供先进先出(FIFO)的消息传递。
- Azure 表存储: Azure 表是一种非关系型、键值对存储系统,适用于存储大量非结构化数据。像表存储这样的非关系型存储针对简单检索和快速插入进行了优化。
- 带有 ExpressRoute 的 Azure 虚拟网络:Azure ExpressRoute 使您能够在 Azure 数据中心与位于您场所或托管环境中的基础设施之间创建专用连接。ExpressRoute 连接不通过公共互联网,与通过互联网的典型连接相比,提供更高的可靠性、更快的速度、更低的延迟和更高的安全性。
背景
什么是物联网
如今,组织正在从物联网 (IoT) 中看到可衡量的收益。公用事业公司通过引入智能仪表,消除了昂贵且不便的上门抄表,智能仪表无需人工干预即可报告更精细的用量数据。这只是物联网实现新产品、新商业模式和新流程的无数种方式的一个例子。
组织可以通过采用物联网获得收益。但我们客户看到的主要收益通常分为三类:改善客户和公民体验、加速增长和业务绩效以及提高安全性并降低风险。这就是为什么今天已经有超过十亿个联网设备和机器在使用。话虽如此,物联网驱动的转型机会在过去几年中已大幅增长,并将继续如此。
关于水务行业
由于世界上许多地区面临严重的缺水状况,水务公司认为有必要采用智能水表系统。这将有助于降低成本、管理抄表等。然而,此类系统的成本可能高得令人望而却步。水行业在智能水表的使用方面远远落后于电力行业。
大多数公用事业公司都无法负担构建专用无线网络或拥有服务器和复杂分析软件的数据中心。我们设计了一种经济高效的智能水表解决方案,该解决方案使用现有无线网络进行水表数据传输,并使用 Microsoft Azure 进行数据管理。
Microsoft Azure
Microsoft Azure 在此解决方案中发挥了至关重要的作用,从使用云上的各种服务到管理这些服务,但最有用的是在性能、上市时间和成本效益方面。此解决方案中使用的其他服务是一个Web 角色,它在 PaaS 上托管应用程序代码。还建立了一个像带有 ExpressRoute 的虚拟网络这样的基础设施服务,用于私有和专用通信,为公用事业仪表提供安全的通信环境,并避免数据安全问题。
现在,Azure 在过去几年中已有所改进,提供了不同的服务,甚至可以进一步增强此类解决方案。诸如 Azure 机器学习、提供实时分析的流分析、事件中心等服务,可以在两个 Azure 服务之间更快地处理大量数据。随着我们前进,我们将看到这些 Azure 组件如何在此解决方案中使用。
入门
让我们开始实施水务计量数据管理系统。水务计量表通过无线网络以双向通信方式收集每日消耗数据,并将其发送到 Azure 云服务。这种通信方式通过托管在 Azure PaaS 上的 WCF 服务(作为云服务)以及现场装有嵌入式代码和无线芯片的计量表进行。
此解决方案分为以下步骤
- 公用事业仪表收集每日消费数据
- 使用数据从仪表传输到云服务
- 从云服务发送指令到仪表以更新固件、配置和需要收集的数据集。
- 使用 Web 应用程序显示消耗数据
架构
在嵌入式代码上工作的硬件设备。它具有 2G 无线功能和 CDMA 协议。我们实现了带有 Azure ExpressRoute 的虚拟网络。它使您能够在 Azure 数据中心与您现场或托管环境中的基础设施之间创建专用连接。ExpressRoute 连接不通过公共互联网,与典型的互联网连接相比,提供更高的可靠性、更快的速度、更低的延迟和更高的安全性。
当仪表连接到云服务时,数据会被解析并添加到服务总线队列组件中。此消息会在工作角色中池化,并推送到 Azure 表存储——Azure 提供的强大 No-SQL 存储。
使用服务总线队列有助于提供更快的数据处理。仪表到云服务的通信时间缩短了仪表的电池寿命。服务总线队列还帮助我们优化了仪表的使用,从而将仪表的电池寿命延长至 8-10 年。一旦电池耗尽,我们需要更换硬件设备本身。
这只是一个单一的通信实例,通过这种架构,我们能够每天处理超过 500,000 笔事务,而且仅在 5 小时内完成。
存储在 Azure 表存储中的这些数据被围绕它构建的不同解决方案使用,例如 Web 应用程序和机器学习,以提供预测分析。
智能电表
智能公用事业仪表为我们提供了各种好处,例如消除了基础设施障碍。它还为水务公司及其客户提供了对用水量的深入了解。
通过使用云,它将开发时间缩短了 50%,并可扩展以适应数万亿次事务。
这些仪表基于 CDMA,通过互联网进行通信以连接 Azure 服务,从而创建了一个完美的“物联网”解决方案。
在项目开始时,我们需要一个支持嵌入式代码的硬件仪表,以收集消耗日志,然后将这些数据传递给云服务,在那里数据得到处理。这种通信是以十六进制数据的形式,通过无线信号以 HTTP 数据包的形式传递的。
读取数据并连接到 Azure
仪表负责模拟通信。仪表将其配置存储在其小容量内存中。这些配置可以是发送数据的 URL。下面是仪表如何调用云服务的示例。
当从仪表到云服务的输入通信建立时,它会收到一个 HTTP 数据包作为流对象,如以下代码片段所示
下一步是将这些数据传递到服务总线队列,并向公用事业仪表回复数据接收确认。这样,我们也减少了电池供电的公用事业仪表的等待时间,从而延长了仪表的使用寿命。
添加了在后台运行并进行处理的 Azure 工作角色,这是一个在 Azure 中持续运行的服务,它轮询数据。
一旦从服务总线队列中检索到此输入,就会对其进行不同的验证处理,然后进入下一步,即将数据存储到 Azure 表存储中。此 No-SQL 组件与基于主键和行键的点查询有效配合。
消费报告
以下是向消费者详细显示的用量数据,这些图表显示了用户每月消耗的数据,
关注点
该解决方案的核心挑战是提高性能,从而减少电池消耗,延长设备寿命。机器学习服务用于创建不同的预测,这将帮助我们获得更多 Microsoft Azure 的优势。同样,公用事业公司可能会对基于其维护的历史数据预测仪表消耗感兴趣。类似地,对电池使用情况进行了预测,如果在 Azure ML 中实施此实验后,电池电量低于某个阈值,它将发送警报。
如果您对任何讨论感兴趣或有任何问题,可以联系 prakash@snp.com 获取详细信息。
Azure IoT: http://www.microsoft.com/en-in/server-cloud/internet-of-things.aspx
Azure 云服务 : http://azure.microsoft.com/en-us/services/cloud-services/
Azure 机器学习 : http://azure.microsoft.com/en-in/services/machine-learning/
Azure Express Route: http://azure.microsoft.com/en-us/services/expressroute/
Azure 表存储: http://azure.microsoft.com/en-in/documentation/articles/storage-dotnet-how-to-use-tables/
历史
2015-02-22:第一份完成的草稿.