引言

为了跟踪小区级的微环境质量，腾讯内部发起了一个实验性项目：细粒度的分布式大气监测。

我们希望基于腾讯完善的产品与技术能力，与志愿者们共同建设一套用于监测生活环境大气的系统，监测终端就分布在志愿者的身边，所以这个系统的数据，更贴近每个人的生活空间，以及提供更细粒度的数据监测能力。

上一期我们分享了分布式大气监测系统的组成和追踪分析，本篇文章将延续之前文章的脉络，从系统架构的角度来介绍目前正在构建的大气监测系统，并逐个模块介绍其设计思路和要点。

设计要求

1. 低使用门槛

这套系统将要吸引志愿者一起共建大气监测点，所以必须保证在端侧及平台操作上都应该尽可能简单。

2. 低开发成本

大气监测是一个典型的端云配合的物联网场景。我们了解到腾讯云已经有了一整套的物联网产品。为了让我们这个兼职部队，在业余时间能快速地构建一个高可靠的业务系统，我们会尽可能地使用腾讯云的物联网产品及其他云产品，用以加速这套业务系统开发。

3. 更多元的扩展空间

以单项监控服务为起点，孵化一套具备快速扩展和广泛适用能力的监测物联网架构，同时以大气监测为案例，进行可用性验证。

架构详细设计

1. 总体设计

整个系统计划由如下几个模块组成：

数据采集模块：在终端侧采集传感器的监测数据。
无线接入模块：提供多种无线协议，支持终端接入网络。
设备接入模块：在云平台侧处理各种无线接入协议及设备数据规整。
业务处理模块：管理终端设备，分析传感器数据及可视化。

架构概要设计图如下所示：

2. 数据采集模块

数据采集模块负责在终端侧采集传感器的监测数据。

这里有2个设计要求：

支持多样化的传感器。我们的系统应该不限制传感器的品牌，这样数据源会有不同的精度和协议格式，需要架构上做些处理。
支持多样化的终端硬件。开发者手头物联网开发板，我们系统应支持尽量多的开发板，保证项目的可玩性，吸引极客们加入进来。

模块设计思路 ：

端侧不处理传感器数据。一方面传感器存在精度差异，一方面有别于政府专用监测点，生活监测点必然存在数据干扰，基于这两点无法保证端侧的数据准确性。设计上端侧不处理传感器数据，在平台汇聚后由业务处理模块进行区域数据分析，滤除个例误差。
端侧不限制传感器数据格式。开发者可能会对接多种传感器，不同品牌、不同型号的传感器均可能存在不同的数据格式，为了减少端侧的开发工作量，借助“设备接入模块”的平台设备数据解析引擎，传感器数据可以在后端在做协议格式规整。
端侧不限制硬件形态。腾讯物联网终端操作系统（TencentOS tiny）是腾讯面向物联网领域开发的实时操作系统，已经对接了市面上主流的芯片架构以及物联网开发板，通过 TencentOS tiny 输出 example 指导开发者。同时其他开发者也可基于 Arduino、树莓派等硬件形态开发相应终端，我们通过社区传播优秀的接入实践教程，进一步丰富终端硬件形态。

3. 无线接入模块

无线接入模块提供多样的无线接入方式，让终端入网并接入设备接入平台。

无线接入这边有一个硬性要求，大部分终端应该都安装在室内及阳台，仍需要部分终端安装于街道上，用以监测户外真实的大气环境。

模块设计思路 ：

由于 LPWAN 具有低功耗、远距离等优势，我们可选用 LPWAN 相关技术来满足户外街道的终端接入需求。目前最主流的是 LoRa 和 NB-IoT 两种无线接入方式。

NB-IoT 同 GPRS 一样，都要购买 sim 卡；LoRa 则需要购买 LoRaWAN 网关。二者都存在一定的搭建成本。但在 LoRa 方面，鹅厂提供了开放共享的腾讯 LoRa 社区网络，其中包括腾讯在深圳自建的数百个LoRa网关，用户可查找附近的社区LoRa网关就近完成 LoRaWAN 设备接入，降低应用开发门槛。

同时考虑在成本和便利性的优势，市面上一个WiFi开发板在20块钱左右，直接通过家庭路由器便可以接入平台，因此我们仍希望能支持 WiFi 接入方式。

综上，在无线接入模块的设计，我们首选 LoRa、辅以 WiFi，同时仍能尽量支持其他的无线接入方式。

4. 设备接入模块

设备接入模块负责各类终端设备的平台侧接入，并且进行不同设备协议的规整，发送给业务处理模块。

为了让业务系统快速支撑海量物联网设备连接，毫无疑问需要选择成熟的物联网平台进行开发。腾讯云物联网开发是目前腾讯云主推的一站式开发平台。除了具备海量连接的可靠能力，还支持 LoRa、WiFi、蜂窝网络等多种接入协议。

另外很重要的一点，腾讯云物联网开发平台还为用户提供产品开发及定义数据模板的能力，可以定义统一的大气传感器产品。同时灵活的设备数据解析引擎，可以将不同的传感器协议格式进行脚本处理，转化成我们需要的统一的数据模版格式，满足我们端侧不限制传感器数据格式的需求。

最后物联网开发平台中可以配置相应的第三方服务器 URL，将规整后的设备协议推送给我们的业务处理模块。

5. 业务处理模块

业务处理模块负责管理终端设备，分析传感器监测数据。

在设备管理部分的设计中，由于物联网开发平台已经可以定义具体数据模版的产品，因此我们在这个大气监测系统将会定义具体的几种大气监测产品，如pm2.5，如voc。业务处理模块中只需进行指定产品的设备管理，用户无需再操心具体的产品json协议，降低用户的使用门槛。

在业务处理部分，涉及API网关、SCF云函数、云数据库及腾讯云图等多款云端组件，eckygao 已在系统功能与架构概述中进行了的阐述。

案例解析

春节前我们快速讨论确定了这套系统架构。并且在 TencentOS tiny 团队的帮助下，在不到2天的时间内，快速搭建了整套系统及5个监测点。

下文介绍具体案例，方便大家加深理解这个系统架构。

1. LoRa PM2.5 节点

在数据采集部分，我们采用了目前 NUCLEO LoRa 开发套件作为主控，串口连接攀藤 PMS7003 PM2.5 传感器。

软件上基于 TencentOS tiny 快速开发了一个固件版本，后续相关同事会再分享一篇具体的嵌入式软件设计分析。下图是具体的传感器数据协议，开发板直接透传数据 payload 给到云端。

2. LoRa 网关

在无线接入部分，5 个监测点直接安装了 5 个社区LoRa网关。

3. 腾讯云物联网开发平台

传感器的原始数据上传到腾讯云物联网开发平台后，经过设备数据解析脚本的处理，原始的传感器协议格式已转化为具体的产品属性，以json格式推送给大气监测平台。

如下是针对攀藤 PMS7003 PM2.5 传感器编写的数据解析脚本：

function RawToProtocol(fPort, bytes) {
    var data = {
        "method": "report",
        "clientToken" : new Date(),
        "params" : {}
    };
    var i = 0;
    
    data.params.PM1_CF1 = (bytes[i++] << 8) | bytes[i++];
    data.params.PM2d5_CF1 = (bytes[i++] << 8) | bytes[i++];
    data.params.PM10_CF1 = (bytes[i++] << 8) | bytes[i++];
    
    data.params.PM1 = (bytes[i++] << 8) | bytes[i++];
    data.params.PM2d5 = (bytes[i++] << 8) | bytes[i++];
    data.params.PM10 = (bytes[i++] << 8) | bytes[i++];
    
    data.params.particles_0d3 = (bytes[i++] << 8) | bytes[i++];
    data.params.particles_0d5 = (bytes[i++] << 8) | bytes[i++];
    data.params.particles_1 = (bytes[i++] << 8) | bytes[i++];
    data.params.particles_2d5 = (bytes[i++] << 8) | bytes[i++];
    data.params.particles_5 = (bytes[i++] << 8) | bytes[i++];
    data.params.particles_10 = (bytes[i++] << 8) | bytes[i++];
    
    data.params.version = bytes[i++];
    data.params.Error = bytes[i++]
    
    return data;
}

下图是 LoRa PM2.5 节点在物联网开发平台中的设备属性呈现：

4. 业务平台最终效果

最后再附上一张大气监测平台的腾讯云图呈现效果。

鹅厂“手搓一个分布式大气监控系统”系列正在持续更新中，欢迎大家持续关注，解锁更多精彩内容~

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/LRl_XzmyxauG2EJ0qBvjPg

创作场景

鹅厂分布式大气监测系统：架构介绍及案例解析