ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

基于Hi3861与鸿蒙的工业物联网终端设计：井下环境监测实战

2026/8/8 7:17:06 拓冰建站 浏览量
基于Hi3861与鸿蒙的工业物联网终端设计：井下环境监测实战

1. 项目缘起：为什么是Hi3861与鸿蒙？

最近在做一个挺有意思的工业物联网项目，客户的需求是在煤矿井下部署一套环境监测系统，实时采集瓦斯浓度、温湿度、一氧化碳等关键数据，并上传到地面监控中心。这个场景听起来简单，但实际落地时，选型和设计上的坑一个接一个。最核心的矛盾在于：井下环境复杂，对设备的功耗、体积、通信稳定性和成本都有近乎苛刻的要求，同时还要考虑未来系统的可扩展性和维护便利性。

传统的方案要么是用有线RS485/以太网，布线成本高、灵活性差；要么是用Zigbee/LoRa这类低功耗广域网，但网关部署和网络管理又是麻烦事。我们团队评估了一圈，最终把目光锁定在了WiFi方案上。你可能要问，井下WiFi信号能行吗？实际上，现在很多现代化矿井都部署了工业级的本安型WiFi网络，作为人员定位、通信和部分数据传输的基础设施，信号覆盖已经不是大问题。关键在于，我们需要一个能无缝接入现有WiFi网络，且足够“轻量”的终端节点。

这就是Hi3861进入我们视野的原因。它是一款基于RISC-V架构的WiFi SoC，集成了完整的802.11b/g/n协议栈和丰富的接口（GPIO, I2C, UART, ADC等），最关键的是，它原生支持鸿蒙（OpenHarmony）轻量系统。这意味着我们可以用一套统一的鸿蒙开发框架，从设备端的嵌入式应用到手机/PC端的监控应用，实现全栈开发，极大地降低了开发和后期维护的复杂度。这个项目，就是基于Hi3861 WiFi模组，设计一个智能井下环境监测的终端节点，并配套开发一个鸿蒙应用进行数据展示。

2. Hi3861模组选型与核心能力拆解

选型不能光看芯片型号，得落实到具体的模组上。市面上基于Hi3861的模组不少，我们最终选择了一款符合矿用本安要求的型号。这里重点不是推荐具体品牌，而是分享选型时要关注的几个核心点，这些点直接决定了后续开发的难易度和系统稳定性。

2.1 硬件接口与供电设计

Hi3861本身资源有限，模组厂商的二次设计就至关重要。我们选的模组，除了引出必要的UART、I2C和ADC接口用于连接传感器，还内置了一个LDO稳压电路，支持宽电压输入（例如3.3V-5V）。这对于井下设备非常重要，因为供电线路长，电压可能会有波动。模组本身的工作电流在WiFi活跃时峰值约200mA，待机时能降到mA级以下，配合合理的休眠策略，用电池或本安电源供电是可行的。

注意：务必仔细阅读模组的数据手册，确认其GPIO的驱动能力和电平标准。我们曾遇到过模组GPIO驱动电流不足，无法直接驱动某些型号的传感器，中间不得不加了一级三极管驱动电路，增加了复杂度和故障点。

2.2 内置的鸿蒙（OpenHarmony LTS）系统版本

这是选择Hi3861模组的决定性因素。模组出厂时通常已经烧录了特定版本的OpenHarmony轻量系统固件。你需要确认这个版本，比如是OpenHarmony 3.0 LTS还是3.2 LTS。不同版本的API和支持的组件可能有差异。我们的模组预装的是3.0 LTS，这个版本对WiFi和Socket的网络支持已经比较稳定，但像MQTT这样的高级网络组件需要自己移植或使用三方库。

2.3 WiFi性能与天线设计

井下环境金属设备多，结构复杂，对WiFi信号的衰减和反射很严重。因此，模组的WiFi性能，特别是接收灵敏度（RX Sensitivity）和天线设计是关键。我们选的模组采用了板载陶瓷天线，并通过了相关射频认证。在实际部署前，我们做了简单的穿透测试：在模拟的金属巷道环境中，模组与距离50米外的AP（接入点）仍能保持稳定的连接。当然，实际矿井中需要专业的网络规划。

3. 监测终端设计：从传感器到数据帧

终端设备的核心任务就三件事：采集、处理、发送。下面我拆开来讲讲每个环节我们是怎么做的，以及遇到的坑。

3.1 传感器选型与驱动适配

井下环境监测，传感器的可靠性和精度是生命线。我们选用了催化燃烧式瓦斯传感器、电化学一氧化碳传感器和数字温湿度传感器。前两者输出通常是模拟量（电流或电压），后者通过I2C或UART数字接口通信。

对于模拟量传感器，Hi3861内置了12位ADC，但精度和抗干扰能力需要仔细处理。我们在硬件上为每个模拟输入通道增加了RC滤波电路，软件上则采用了中位值平均滤波算法。以下是ADC采样的一个核心代码片段：

#include "ohos_init.h" #include "cmsis_os2.h" #include "hi_adc.h" #define CHANNEL_NUM 0 // ADC通道号，根据实际接线定义 #define NUM_SAMPLES 10 // 采样次数 static float ReadGasSensorValue(void) { unsigned int raw_value; float voltage; int samples[NUM_SAMPLES]; int i, j, temp; // 1. 多次采样 for (i = 0; i < NUM_SAMPLES; i++) { hi_adc_read(CHANNEL_NUM, &raw_value, HI_ADC_EQU_MODEL_1, HI_ADC_CUR_BAIS_DEFAULT, 0); // Hi3861 ADC参考电压通常为1.8V或3.3V，需根据具体模组确定 // 假设参考电压Vref=3.3V，12位精度 voltage = (raw_value * 3.3) / 4096.0; // 将电压值根据传感器数据手册转换为浓度值（例如ppm） // 此处简化处理，实际需要校准曲线 samples[i] = (int)(voltage * 1000); // 示例转换 osDelay(2); // 短暂延时，避免采样过密 } // 2. 中位值平均滤波：先排序，去掉最大最小，再平均 for (i = 0; i < NUM_SAMPLES - 1; i++) { for (j = 0; j < NUM_SAMPLES - 1 - i; j++) { if (samples[j] > samples[j + 1]) { temp = samples[j]; samples[j] = samples[j + 1]; samples[j + 1] = temp; } } } int sum = 0; for (i = 1; i < NUM_SAMPLES - 1; i++) { // 去掉首尾（最大最小值） sum += samples[i]; } return sum / (NUM_SAMPLES - 2); }

对于I2C温湿度传感器，鸿蒙提供了//device/soc/hisilicon/hi3861v100/sdk_liteos/hardware/i2c的驱动接口，但使用起来需要仔细配置时序。最大的坑在于，有些传感器从机的应答速度慢，需要调整I2C总线超时时间，否则会一直返回失败。我们是在底层驱动里适当增大了超时阈值才解决的。

3.2 数据协议设计与帧组装

数据上传不能是乱流，必须有固定的格式，即协议。我们设计了一个简单的二进制协议，兼顾了可读性和传输效率。一帧数据包括帧头、设备ID、数据体、校验和。

#pragma pack(1) // 按1字节对齐，避免结构体空洞 typedef struct { uint16_t header; // 帧头，固定为0xAA55 uint8_t devId[6]; // 设备MAC地址作为ID uint32_t timestamp; // 时间戳 uint16_t gasConc; // 瓦斯浓度，单位0.1%LEL int16_t temperature; // 温度，单位0.1℃ uint16_t humidity; // 湿度，单位0.1%RH uint16_t coConc; // CO浓度，单位1ppm uint8_t battery; // 电池电量，百分比 uint8_t rssi; // WiFi信号强度 uint16_t checksum; // CRC16校验和 } SensorDataFrame_t; #pragma pack()

帧组装就是在内存中填充这个结构体。校验和我们用了CRC16-CCITT算法，确保数据在传输过程中的完整性。这里有个细节：结构体中的timestamp（时间戳）我们并没有使用Hi3861的RTC（因为它没有独立的硬件RTC，且断电会丢失），而是在每次上电后通过NTP从服务器获取一次初始时间，然后依靠系统tick来推算。虽然会有累积误差，但对于非严格计时的环境监测可以接受。

3.3 低功耗与任务调度策略

井下设备很多地方无法方便取电，低功耗设计是延长设备寿命的关键。Hi3861支持深度睡眠（Deep Sleep），但一旦进入深度睡眠，WiFi连接会断开，唤醒后需要重新关联网络，耗时且耗能。我们的策略是采用“轻度休眠+心跳上传”模式。

我们创建了两个任务：一个高优先级的数据采集处理任务，一个低优先级的网络通信任务。系统大部分时间处于“空闲”状态，由采集任务定时（例如每10秒）唤醒，读取传感器数据并存入环形缓冲区。网络通信任务则以更长周期（例如每60秒）唤醒一次，检查缓冲区是否有新数据，如果有，则组帧并通过WiFi发送。没有数据发送时，WiFi模组会自动进入省电模式（PS-Poll）。这种设计在数据实时性和功耗之间取得了较好的平衡。

4. 网络通信核心：WiFi连接与MQTT封装

这是项目中最具挑战性的部分之一。Hi3861的鸿蒙系统提供了基础的Socket API和WiFi连接管理API，但直接使用Socket进行TCP通信并管理重连、心跳等逻辑非常繁琐。我们的目标是封装一个稳定、易用的MQTT客户端。

4.1 WiFi连接与保活机制

鸿蒙提供了//foundation/communication/wifi_lite组件用于WiFi操作。连接AP的基本流程是：扫描 -> 选择目标AP -> 输入密码连接。但在工业环境，网络可能不稳定，必须要有自动重连机制。

我们实现了一个WiFi管理状态机，核心状态包括：DISCONNECTED（断开）、SCANNING（扫描）、CONNECTING（连接中）、CONNECTED（已连接）、RECONNECTING（重连中）。在CONNECTED状态下，我们会启动一个保活线程，定期（比如每30秒）ping一下网关或者一个已知的服务器IP。如果连续多次ping失败，则状态机自动跳转到RECONNECTING，重新执行扫描和连接流程。

实操心得：不要一检测到断开就立刻重连，最好加入一个随失败次数递增的延时（例如1s, 2s, 4s, 8s...），即“指数退避”算法。这能避免在AP短暂故障或信号瞬间不佳时，设备频繁发起连接请求，消耗电量并可能加重网络负担。

4.2 MQTT客户端封装与选型

OpenHarmony 3.0 LTS的标准库并没有提供MQTT客户端。我们有三个选择：1. 自己基于Socket实现MQTT协议；2. 移植一个开源的轻量级MQTT C库（如Eclipse Paho MQTT C）；3. 使用厂商提供的SDK。

自己实现协议栈工作量巨大且容易出bug，首先排除。厂商SDK可能绑定特定云平台，灵活性差。因此，移植开源库是最佳选择。我们选择了Paho MQTT C的嵌入式版本（MQTTClient-C），它代码简洁，依赖少，非常适合Hi3861这种资源受限的设备。

移植工作主要涉及以下几方面：

  1. 网络接口适配：Paho库底层需要调用send()和recv()等Socket函数。我们需要实现一个Network结构体，将其函数指针指向鸿蒙系统的Socket API。
  2. 内存管理：将库中动态内存分配（malloc/free）替换为鸿蒙的osMemoryAlloc/osMemoryFree，或者直接使用静态内存池，以提高确定性和避免内存碎片。
  3. 定时器：MQTT需要心跳保活，库内部使用了定时器。我们需要实现一个基于鸿蒙osKernelGetTickCount的毫秒级定时器接口。
  4. 日志输出：将库中的printf调试信息重定向到鸿蒙的printf或自己的日志系统。

封装后的MQTT客户端，我们对外提供了几个简洁的接口：

// 初始化并连接MQTT服务器 int MQTT_ClientInit(const char* server_ip, int port, const char* client_id); // 订阅主题 int MQTT_Subscribe(const char* topic); // 发布消息 int MQTT_Publish(const char* topic, const char* payload, int qos); // 处理网络数据包和心跳，需在主循环中定期调用 void MQTT_Yield(int timeout_ms); // 断开连接并释放资源 void MQTT_ClientDeinit(void);

4.3 数据上传与服务器交互

数据上传的Topic我们设计为：/mine/env/{devId}/upload，其中{devId}替换为设备的MAC地址。消息体就是前面组装的二进制帧，但为了兼容性，我们将其进行了Base64编码后再作为MQTT Payload发送。服务器（Broker）端订阅此Topic，收到后解码、校验、解析并存入数据库。

同时，设备也订阅了一个命令Topic：/mine/env/{devId}/cmd。服务器可以通过此Topic下发指令，例如：修改采集上传周期、请求实时数据、远程重启等。这实现了对设备的反向控制。

5. 鸿蒙应用开发：数据可视化与监控

设备端的数据需要有一个直观的展示界面。我们利用鸿蒙的分布式能力和统一的开发框架，开发了一个运行在手机或平板上的鸿蒙应用。这里主要分享几个关键点的实现。

5.1 应用与设备的发现与绑定

理想状态下，鸿蒙设备之间可以通过软总线自动发现。但在我们的场景中，井下监测终端数量多且网络环境复杂，通过软总线直接发现并不稳定。我们采用了“云端中介”的模式：

  1. 设备上电连接MQTT后，向一个特定的注册Topic（如/mine/env/register）发布自己的设备信息（ID、名称、位置编码等）。
  2. 鸿蒙应用启动后，同样连接MQTT服务器，订阅注册Topic和所有设备的数据上传Topic（可以使用通配符/mine/env/+/upload）。
  3. 应用收到注册消息后，将设备添加到本地设备列表。用户可以在列表中选择需要重点监控的设备，实现“逻辑绑定”。
  4. 应用收到绑定设备的数据后，进行解析和展示。

5.2 数据解析与实时图表绘制

应用端收到Base64编码的二进制数据后，先解码，再按照同样的结构体定义进行解析。这里要注意字节序（Endian）问题，我们统一使用了小端序（Little-Endian）。

对于数据展示，我们使用了鸿蒙的Chart组件来绘制历史曲线图。由于鸿蒙应用开发框架（ArkUI）的Chart组件功能还在不断完善中，我们遇到了一些性能问题。当需要同时展示多个传感器、且数据点较多（例如一天的数据）时，直接渲染会导致UI卡顿。

解决方案是进行数据采样和分页加载：

  • 实时视图：只显示最近1小时的数据，并且每收到一条新数据就更新图表。
  • 历史视图：当用户查看更长时间范围（如一天）时，我们不将所有原始数据点都交给Chart组件，而是在后端先进行降采样。例如，对于一天86400秒的数据，我们将其划分为1440个区间（每分钟一个点），取每个区间内的最大值、最小值、平均值三个点，用“蜡烛图”的形式展示，既能反映趋势，又能看到波动范围，同时数据量从86400个点减少到4320个点，渲染压力大大降低。

5.3 告警功能与分布式通知

当解析到的瓦斯浓度、一氧化碳浓度超过安全阈值时，应用需要立即告警。我们实现了两级告警：

  1. 应用内告警：在应用界面顶部用红色横幅显示告警信息，并播放告警音。
  2. 分布式通知：利用鸿蒙的分布式能力，将关键告警信息同步到用户的其他鸿蒙设备上，例如智能手表。即使手机应用不在前台，用户也能通过手表震动及时感知。

这里用到了鸿蒙的@ohos.distributedNotificationManager模块。关键代码如下（以JS/ETS为例）：

import distributedNotificationManager from '@ohos.distributedNotificationManager'; import common from '@ohos.app.ability.common'; // 发布一个分布式通知 async function publishAlarmNotification(context: common.Context, alarmMsg: string) { let request: distributedNotificationManager.NotificationRequest = { content: { contentType: distributedNotificationManager.ContentType.NOTIFICATION_CONTENT_BASIC_TEXT, normal: { title: '井下环境告警', text: alarmMsg, // ... 其他通知参数 } }, // ... 其他请求参数 }; try { await distributedNotificationManager.publish(request); console.info('Alarm notification published successfully.'); } catch (err) { console.error(`Failed to publish alarm notification. Code: ${err.code}, message: ${err.message}`); } }

6. 系统集成测试与井下部署要点

实验室跑通只是第一步，真正的考验在井下。我们总结了几个部署前后的关键测试点和注意事项。

6.1 模拟环境压力测试

在实验室，我们搭建了一个简单的测试环境：用金属柜模拟井下巷道，将设备放入，AP放在柜外。测试内容包括：

  • 长时间稳定性测试：让设备连续运行72小时以上，观察是否有死机、内存泄漏、数据丢失等情况。我们通过日志发现，运行约20小时后，MQTT客户端偶尔会因网络抖动而进入一个错误状态无法恢复。最后发现是网络断连处理逻辑中，没有正确重置某个内部状态标志，修复后问题解决。
  • 网络异常测试：手动开关AP，模拟网络中断。检查设备重连机制是否有效，重连后数据是否能续传（我们设计了简单的本地缓存，最多存50条数据，网络恢复后优先发送缓存数据）。
  • 多设备干扰测试：同时让10台设备接入同一个AP，频繁上报数据，测试AP的带机量和网络拥堵情况下的数据丢包率。结果发现，当所有设备同时以1秒为周期发送数据时，丢包率显著上升。这促使我们将上报周期调整为错峰随机（例如基准60秒，加上一个-5到+5秒的随机偏移），有效降低了网络峰值压力。

6.2 井下部署安装规范

井下安装绝非简单地把设备挂墙上，必须遵守安全规范。

  • 设备选型与认证：所有下井的设备，包括Hi3861模组、传感器、电源、外壳，都必须具备“矿用产品安全标志证书”（MA标志）和“防爆合格证”。我们选用的整套设备是经过认证的本安型设备。
  • 安装位置：瓦斯传感器应安装在巷道顶板下方，距顶板不大于300mm，距侧壁不小于200mm，因为瓦斯比空气轻。一氧化碳和温湿度传感器的安装高度则根据其密度和监测需求而定。
  • 供电与布线：电源必须来自矿井安全供电系统。信号线、电源线必须穿管保护，接头处使用防爆接线盒。
  • 天线处理：WiFi天线位置应尽量避开大型金属设备遮挡，朝向AP方向。如果使用外置天线，天线本身也需是防爆型。

6.3 运维与远程诊断

设备部署后，运维同样重要。我们为设备端增加了几个远程诊断功能：

  1. 心跳与状态上报：除了传感器数据，设备定期（如每10次数据上报一次）发布状态信息到/mine/env/{devId}/status，包含电池电压、信号强度（RSSI）、内部温度、运行时长、错误码等。
  2. 远程日志级别调整：通过命令Topic，可以动态调整设备端的日志输出级别（如DEBUG, INFO, ERROR）。当某个设备出现问题时，可以将日志级别调高，获取更详细的运行信息辅助排查。
  3. 固件远程升级（OTA）：我们预留了OTA接口。服务器可以通过MQTT下发新固件的下载地址和校验码，设备在空闲时下载、校验并写入备份分区，下次重启时切换分区启动。这是保证系统长期可维护性的关键功能，但第一次实现时要极其小心，必须做好版本回滚和断电保护机制，避免变“砖”。

这个基于Hi3861和鸿蒙的智能井下监测系统，从芯片选型到协议设计，再到应用开发，是一套完整的软硬件结合解决方案。它最大的优势不在于用了多高端的技术，而在于用一套统一的、开源的鸿蒙生态，将嵌入式端、通信端和应用端串联起来，降低了长期的技术维护成本和人员学习成本。在实际项目中，稳定性和可靠性永远是第一位的，任何花哨的功能都必须为这两点让路。