答辩 | 🐟🐟's blog

语音识别算法

采用ASR-PRO开发板，集成神经网络处理器与CPU内核，显著提升了语音识别的实时性和准确性，无需依赖云端。

支持本地化语音处理，为了提升对方言及特殊人群（如老人、儿童）发音特征的识别能力，系统引入了先进的自然语言处理（NLP）和声纹识别技术。通过分析语音的音频特征，并与预先注册的音频特征进行比对，系统能够有效识别说话人的身份和语言特征。

引入了回声消除与降噪算法，提升复杂环境下的识别准确率。在语音信号处理方面，系统采用了汉明窗函数进行信号加窗处理，减少频谱泄露，提高频率分辨率。

随后，利用梅尔频率倒谱系数（MFCC）对信号进行特征提取，模拟人耳对不同频率声音的感知特性，提取出能够描述语音信号的关键特征参数。这一系列处理步骤大大提高了语音识别模块的稳定性和准确性。

为什么选择 OpenHarmony 作为开发平台？

我选择 OpenHarmony 作为开发平台，主要出于以下几点考虑：

✅ ① 开源开放，生态活跃

OpenHarmony 是开源操作系统，具备良好的开放性和生态支持。我们希望项目不仅能运行在某一个单一设备上，而是具备一定的可移植性和拓展性，而 OpenHarmony 本身就是为多设备协同和多终端互联设计的，契合智能家居场景的需求。

✅ ② 支持轻量化设备

在本项目中，虽然我们提到使用的是 OpenHarmony 平台，但具体所用的 Hi3861 开发板运行的是 OpenHarmony 的轻量化子系统 —— LiteOS-M。这是一个实时、轻量级嵌入式操作系统。适合在低功耗 IoT 设备上（如 Hi3861）

✅ ④ 对接华为云平台的天然优势

OpenHarmony 和 LiteOS-M在 IoT 和华为云之间的联动是官方支持的，对接过程更加顺畅，开发文档、SDK、工具链完善，可以加快开发效率，降低学习成本。同时我们的app开发也是使用的华为自研的DevEco Device Tool和官方的华为云平台，搭载LiteOS-M也更加顺畅。

💡

本项目使用的 Hi3861 实际运行的是 OpenHarmony 的轻量化子系统 —— LiteOS-M。它是专为资源受限设备设计的嵌入式实时操作系统，继承了鸿蒙在分布式架构和设备协同上的设计理念，并与鸿蒙生态兼容，具备良好的云边协同能力。在智能家居场景中，使用 LiteOS 能够在保持低功耗与高响应的同时，支持本地语音识别和云平台互联，达成我们的项目目标。

为什么选择 Hi3861，而不是树莓派或 STM32？

系统原生支持，开发效率高

Hi3861 是 OpenHarmony 和 LiteOS-M 官方首选适配平台，SDK 完整，无需繁琐移植，可以快速上手。同时支持鸿蒙设备开发工具 DevEco Device Tool，提供可视化配置、调试和编译。而树莓派操作系统为完整的 Linux，体积大，启动慢；配置复杂，SD 卡烧录系统、挂载文件系统步骤繁琐，不适合嵌入式快速部署。STM32仅支持裸机/RTOS，系统功能弱；没有官方语音、联网 SDK，需开发者完全自定义移植，开发成本高、周期长。

通信能力强，适配物联网环境

Hi3861片上集成 Wi-Fi 模块,支持 TLS、MQTT、LwM2M 等主流 IoT 协议，直接对接云平台如华为云、阿里云。但STM32自身不具备通信能力，需外挂 ESP8266、W5500 等模块，通信驱动需自行编写或移植，可靠性、稳定性不如原生 Wi-Fi 芯片。树莓派虽然支持 Wi-Fi，但本质为桌面级设备，联网后功耗高、网络管理复杂同时缺乏对轻量物联网协议。

低功耗、高集成，适合终端落地

智能家居的典型特征是：常开、低功耗、低维护。Hi3861 的超低功耗运行模式和片上集成的方案非常适合部署在插座、灯控、空调面板等家电终端。树莓派功耗高，不适合常驻设备；STM32虽低功耗，但处理能力受限。

成本可控，适合批量部署

一块 Hi3861 普中开发板的成本在几十元以内，相比树莓派便宜 5～10 倍，且比 STM32 加 Wi-Fi 模块更紧凑稳定，非常适合工业产品或大规模实际部署。

如何确保系统的数据安全和用户隐私？

我们从硬件层、传输层和云端处理三方面构建了完整的数据安全与隐私保护机制：

硬件层安全

我们使用的 Hi3861 开发板内置安全引擎（Hardware Security Engine, HSE），支持 AES、SHA、RSA 等硬件级加解密算法，在设备端对敏感数据进行本地加密处理，有效防止在边缘节点发生数据泄露。

传输层安全

设备与云平台通信采用 MQTT over TLS（端口 8883） 协议，结合 SSL/TLS 加密通道，通过非对称加密方式保障数据传输过程中的机密性和完整性，防止中间人攻击和数据篡改。同时 MQTT 协议本身支持 QoS 等机制，增强了通信可靠性。

云端平台安全

我们采用的是 华为云 IoTDA 平台，它具备完善的设备身份认证机制（如预共享密钥/证书方式），并支持细粒度的 权限控制与数据隔离策略，确保不同用户/设备之间数据不可互访。

此外，为了保护用户隐私，我们设计上采取 “隐私本地化”原则：如人脸识别和声纹识别数据均在设备端本地进行处理和判断，不上传原始图像或音频数据至云端，从源头上防止隐私泄露风险。

软硬件之间如何实现互联？

💡

我们的软硬件互联实现分为“南北向架构”和“通信接口机制”两个层次：南向通过 Hi3861 开发板采集并发布数据，北向通过 DevEco App 接入华为云平台进行指令交互。采用 MQTT 协议作为通信桥梁，结合 LiteOS 驱动封装与 IoTDA 平台映射绑定，实现了软硬件之间的实时双向联动，架构清晰，可拓展性强，安全稳定。

我们系统的软硬件互联实现基于“南北向架构设计”与“通信路径机制”两条主线展开，既保证了设备接入的灵活性，也确保了数据传输的实时性与稳定性。

在南向设备层，我们选用 Hi3861 Wi-Fi SoC 芯片开发板，搭载华为自研的轻量级操作系统 LiteOS。该芯片具备较强的边缘计算能力，并内置 硬件加密模块与 MQTT 通信库支持，能够在本地完成语音识别、传感器采集与边缘处理，并通过 MQTT over TLS 的方式将数据安全上传。

硬件层驱动与中间件：在 LiteOS 系统中，我们封装了各类外设驱动（如语音识别模块、麦克风、LED、继电器等），并通过 MQTT 客户端 SDK 提供统一的数据接口层（API）。上层业务逻辑通过调用这些 API 实现**“数据采集→封装消息→发布主题”**的完整链路。

云端平台设备映射与规则配置

在云端 IoT 平台，我们为每个设备生成唯一的 Device ID 并绑定 MQTT 连接身份，实现一一映射。通过 规则引擎和 物模型配置，实现指令下发与数据解析。

在北向应用层，我们使用 DevEco Device Tool 开发了移动端 App，通过调用 华为云 IoTDA 平台的开放 API 实现与云端设备的数据交互。云平台通过 物模型（Thing Model）和设备影子机制，对每台接入设备进行属性映射和状态同步，配合 规则引擎实现指令下发和自动化处理。用户在 App 中的操作，如“打开风扇”，会通过云平台转换为 MQTT 消息下发到指定 Topic，设备订阅后解析指令完成响应控制。

整个系统通过 MQTT 协议作为软硬件之间的通信桥梁，构建了典型的“发布-订阅模型”，不仅简化了消息管理，也实现了异步、高效的数据交互。同时，借助 TLS 加密、设备唯一身份认证与云端权限控制等机制，系统在互联的基础上也实现了安全可控的通信保障。

为什么使用了两块开发板？

我们的设计基于 “专板专用”原则，两块开发板各司其职：

算力和资源匹配：

Hi3861 作为主控，专注于低功耗设备控制与云端通信；适合处理 轻量级的网络通信任务、传感器数据采集、状态控制等基础逻辑；
ESP32-S3 是一款支持 AI 算法加速的双核 MCU，具备 向量指令集、TensorFlow Lite Micro 加速能力，非常适合处理 高计算量的边缘 AI 任务，例如 人脸识别、图像预处理、边缘检测等复杂算法；
两块板子协同工作，避免了性能瓶颈和单板负载过高的问题。

系统分层解耦，利于稳定与扩展

ESP32-S3 作为 边缘智能处理器，主要关注前端数据的 AI 推理与分析；
Hi3861 则作为 中控网关模块，负责设备通信、状态维护、MQTT 协议交互与云平台连接；
这种模块化设计使得系统结构更清晰，有利于功能扩展、任务迁移和后期维护。

安全与隐私设计考量

我们将涉及用户隐私的 人脸识别任务固定在 ESP32-S3 本地完成，不上云、不外传；
Hi3861 只上传最终识别结果（如身份编号、访客记录等），确保用户敏感数据不会泄露；
这种硬件隔离的设计增强了系统的隐私保护能力，也符合边缘智能设备的发展趋势。

💡

这种分工不仅提升了系统整体性能（如并行处理能力），还通过硬件级隔离增强了稳定性（单板故障不影响全局，避免了性能瓶颈和单板负载过高的问题。）。尽管增加了硬件数量，但通过OpenHarmony的分布式架构，系统仍保持高度集成与易维护性。

两块开发板如何协同工作？

通信机制：串口/UART通信

两块开发板通过 串口（UART）通信协议建立点对点数据链路，通信速率根据任务量设定；ESP32-S3 完成人脸识别后，将识别结果（如用户ID、识别时间、状态码）通过串口发送给 Hi3861；Hi3861 作为中转节点，将结果封装为 MQTT 消息上报至华为云 IoTDA 平台。

模块间职责划分清晰，便于多设备协同扩展

后续如果系统需要支持更多前端识别设备，只需增加 ESP32-S3 节点；所有 ESP32-S3 识别结果都可以通过串口或 BLE 中转到 Hi3861，再统一上报；Hi3861 实际承担的是“通信协调器”和“设备管理中心”的职责。

系统的兼容性如何？能否接入第三方品牌设备？

我们的系统具备良好的兼容性和开放性设计，支持多品牌、多协议的设备接入，主要从以下几个方面体现：

标准协议通信，具备广泛兼容性

系统采用 MQTT协议 作为主干通信协议，该协议是目前物联网领域最主流、最通用的轻量级发布/订阅协议，已被大量主流厂商（如小米、涂鸦、华为、阿里等）设备所支持。
MQTT 是协议层的标准化抽象，只要第三方设备支持 MQTT，即可通过注册 Topic 接入我们系统，实现消息交互和设备控制。

平台对接能力强，兼容主流 IoT 云平台

我们接入的云平台为 华为云 IoTDA，本身就支持标准 MQTT/CoAP/HTTP 协议接入，且提供了统一的设备模型（Thing Model）和桥接能力，可通过：

设备接入SDK（支持C/Java/Python）
网关设备桥接第三方私有协议设备
规则引擎实现云端逻辑转换

因此即使第三方设备使用私有协议，也可通过网关 + 规则引擎完成协议转换与接入。

支持多种接入方式

直接接入方式：若第三方设备支持 MQTT、TLS 等协议，可通过配置 Topic 和权限，直接接入系统；
间接接入方式：若不支持标准协议，可通过我们部署的 Hi3861/ESP32-S3 边缘网关模块，作为中转桥梁完成私有设备的协议封装；
App 控制兼容：我们开发的 DevEco App 已预留设备拓展模块，支持动态加载新的设备类型和控制逻辑（如通过 JSON 配置或插件式控制面板扩展第三方设备 UI 控件）。

示例说明：

比如你想对接一个小米网关设备，只要该设备开放了 MQTT 接口或 HTTP API，我们就可以通过云端规则引擎或边缘网关桥接协议实现对接；

对于 ZigBee 或 BLE Mesh 设备，我们也可以通过外挂 ESP32-S3 模块搭建边缘网关，将其转换成统一的 MQTT 控制接口。

如何实现设备的拓展？即增添新的家居，系统扩展性如何？

我们从以下四个技术层面确保系统具备良好的设备拓展能力和扩展弹性：

系统架构设计具备模块化与分层解耦特性

我们整体采用了模块化架构设计：感知层（设备）—网络层（MQTT网关）—平台层（IoTDA）—应用层（App控制），每一层都独立运行、可热插拔、扩展互不干扰；
比如你要添加一个新的智能窗帘，只需在感知层新增设备节点，对应的网络连接、平台注册、应用控制逻辑分别按层更新即可，不影响原有系统结构。

MQTT协议天然支持多设备拓展

系统采用 MQTT协议 作为主干通信协议，该协议是目前物联网领域最主流、最通用的轻量级发布/订阅协议，已被大量主流厂商（如小米、涂鸦、华为、阿里等）设备所支持。
MQTT 是协议层的标准化抽象，只要第三方设备支持 MQTT，即新增设备可通过注册 Topic 接入我们系统，实现消息交互和设备控制。

设备物模型支持动态定义与自适配

华为云 IoTDA 提供了可视化的设备物模型编辑器，新增家居设备时，只需：

定义设备属性（如电源状态、亮度、色温）；生成新的物模型 JSON；下发给设备端和App解析即可；

App层通过组件化UI适配新增设备

DevEco App 使用了组件化UI框架，每种设备类型都有独立的控件组件（如开关、滑块、温度计）；
新增家居设备时，仅需在设备管理界面动态绑定控件 → 加载物模型定义 → 显示控制界面；

💡

我们系统基于 MQTT 标准通信协议、动态物模型机制和组件化 App 架构设计，天然支持设备拓展。无论是新增家居种类、更新硬件型号，还是对接第三方品牌设备，都能快速接入、快速部署，具有良好的系统扩展性与可维护性，非常适合构建未来可持续迭代的智能家居平台。

MQTT协议实现硬件和云平台之间的消息传输

什么是MQTT协议？

MQTT（Message Queuing Telemetry Transport） 是一种轻量级、发布/订阅（Pub/Sub）模型的消息传输协议，专为低带宽、不稳定网络环境设计，非常适用于物联网（IoT）场景。

MQTT 的三大核心角色

Client（客户端）

你的硬件设备，如 Hi3861、STM32+ESP8266 等

Broker（代理服务器）

消息中转中心，通常部署在云平台（如华为云

Topic（主题）

消息的“标签”，决定了消息的路由路径

MQTT通信架构图

⚙️ 消息传输流程详解

🎯 1. 连接阶段（CONNECT）

硬件设备作为 MQTT 客户端，通过 TCP/IP 建立连接：

协议：TCP（默认端口 1883，或 TLS 加密端口 8883）

内容：客户端 ID、用户名、密码、KeepAlive 心跳等参数

Broker 校验成功后返回 CONNACK

📤 2. 发布消息（PUBLISH）

设备将采集到的本地数据（如语音识别结果、温湿度数据等）通过某个主题发布到云平台：

云端可以订阅 home/device/voice，用于控制动作（如打开灯、启动电扇）。

📥 3. 订阅消息（SUBSCRIBE）

设备也可以订阅来自云端的指令，实现远程控制：

当云端发出命令：

设备通过 MQTT 回调接收到，触发本地控制逻辑。

🔁 4. 心跳保活（PINGREQ / PINGRESP）

设备定期向 Broker 发送心跳包，维持连接：

如果超过该时间没有通信，Broker 会认为客户端掉线，触发离线处理。

🔁 5. 离线重连（自动机制）

MQTT 通常会配置自动重连机制（断网重连、断电续连），保证在不稳定网络下持续通信。

🛡️ 安全性（可选）

TLS 加密传输（端口 8883）

客户端用户名+密码认证

客户端 ID 签名校验（如华为云的 MQTT 接入需设备证书）

🧪 实例：Hi3861 + 华为云 IoT Platform

华为云平台提供 MQTT 接入点地址 和设备认证信息；

在 Hi3861 SDK 中，配置 MQTT 参数：

3.使用 LiteOS-M + Huawei MQTT SDK 建立连接并运行消息逻辑。

💡

MQTT 是本项目硬件与云平台之间的通信桥梁，采用轻量发布/订阅模型，支持断线重连、QoS 确认、心跳保活等机制。硬件设备如 Hi3861 通过内置 Wi-Fi 连接云端 MQTT Broker，发布语音识别结果或状态信息，同时订阅控制指令，形成**“云-端”闭环交互系统**，既保证了通信效率，也具备良好的稳定性和扩展性，非常适合物联网语音控制类场景。

未来创新

Home Assistant（简称 HA） 是一个开源的智能家居自动化平台，基于 Python 开发，运行在本地服务器（如树莓派、NAS 或 PC）上，主要特点包括：

特点	描述
🌐 本地部署	不依赖云端，增强隐私与稳定性
🧩 高度可扩展	支持 2500+ 第三方设备/服务集成（如小米、涂鸦、ESPHome、MQTT）
⚙️ 自动化能力强	支持 YAML 配置、可视化流程编排等多种方式实现家庭自动化
📱 多端访问	支持网页、App、语音助手、NFC 等多终端控制

Hi3861 是否能接入 Home Assistant？

是的，可以接入，前提是通过标准协议桥接，尤其是 MQTT协议。

模块	内容
💡 硬件层	Hi3861 作为边缘设备（传感器/控制器），搭载轻量 MQTT 客户端（如 Paho MQTT）
🔐 安全层	Hi3861 支持 MQTT over TLS（即基于 SSL 加密的 MQTT），保证通信安全
🌐 平台层	Home Assistant 本地部署 MQTT Broker（推荐用 Mosquitto 插件）
🔄 通信机制	Hi3861 发布数据至 MQTT Broker，HA 订阅对应 Topic 实现数据交互与控制

关键配置流程举例（简化版）

HA 安装 MQTT 插件（Mosquitto）
配置 HA 中的 configuration.yaml 添加设备支持：….
在 Hi3861 中嵌入 MQTT Client，连接 HA 的 Mosquitto 服务，并定时发布数据：

语音助手“鸿小伴”与市场上现有产品（如小爱同学）有何差异？

我们开发的“鸿小伴”语音助手，聚焦在特定人群适配、本地部署、安全性和垂直场景控制等维度，与通用型语音助手有明显差异：

🎯 用户定位不同：专注老人/儿童友好设计

特性	鸿小伴	小爱同学/天猫精灵
操作复杂度	离线控制 + 本地命令词，简单直观	多数依赖联网 + App 配置，门槛较高
语言识别优化	加入方言语料库、老人语速适配模型	偏标准普通话，边缘人群识别准确率较低
响应速度	本地神经网络芯片 + 无需联网，响应低延迟	云端识别，需依赖网络质量

硬件深度绑定，支持垂直场景控制

市面上的语音助手（如小爱同学）通常通过云端 API 控制品牌生态产品，但在控制物理设备、读取本地传感器（如温湿度）时，往往需要额外网关或云服务。
我们的“鸿小伴”语音模块与Hi3861主控板直接通信，可本地查询如“当前室温是多少”“现在空气质量怎么样”这类和传感器强绑定的内容，实现了真正的端到端控制闭环，响应速度更快，控制更稳定。
用户说：“鸿小伴，现在多少度？” → 模块直接从本地温湿度传感器读取数据 → 语音播报结果，全程无网络依赖。

隐私保护与本地部署是显著优势

鸿小伴采用本地化部署的语音识别模块（基于 ASR-PRO+LiteOS）;语音数据不上传云端，避免用户对隐私泄露的担忧；减少对网络依赖，在断网情况下依旧可实现关键控制指令
减少对网络依赖，在断网情况下依旧可实现关键控制指令

⚙️ 技术选型差异（适合答辩专家追问时补充）

模块	鸿小伴	小爱同学
操作系统	LiteOS + DevEco套件	MIUI智能生态（封闭）
通信协议	MQTT + TLS + 本地总线（I2C/UART）	基于小米生态私有协议为主
开发模式	可完全开源定制，支持边缘AI	无法直接修改核心识别逻辑
边缘AI支持	内嵌神经网络推理（如人脸+语音）	云端 AI 模型为主，弱化边缘能力

💡

与市场通用语音助手不同，“鸿小伴”定位于特定人群、特定场景，具备更强的可定制性、更高的隐私保护能力与边缘部署优势。它不仅是语音助手，更是本地智能家居系统的智能交互入口，兼具实用性、安全性与可拓展性，适合社区、养老、儿童看护等对本地化控制和数据安全有高要求的场景。

面对智能家居市场的激烈竞争，你们如何脱颖而出？

市场痛点分析（问题导向切入）

当前智能家居市场确实看似繁荣，实则存在三大共性问题：

标准不统一，兼容性差

各家厂商生态封闭，协议不兼容，导致用户无法统一控制不同品牌设备，体验割裂。

隐私风险高，依赖云端

多数语音助手将语音数据上传至云端处理，不仅带来网络延迟，还存在用户隐私泄露风险。

特定人群适配差

市场上的智能语音系统多为通用型，对老人、儿童等特殊人群的语言识别精度不高，交互复杂，不够友好。

我们的技术路线（解决思路）

针对上述问题，我们构建了一个本地部署、软硬件深度融合、面向特定场景优化的智能家居系统，技术上分三层应对：

设备层：基于Hi3861 + ESP32-S3双芯协作

Hi3861 作为主控，负责网络通信与设备联动；
ESP32-S3 用于处理人脸识别等高算力任务，确保安防实时性；
两者通过串口/IoT协议协同，实现分工明确、低功耗运行。

通信层：MQTT + TLS 加密通信

使用 MQTT 协议实现高效、低延迟的发布/订阅模式；
搭配 TLS 实现端到端加密，确保数据传输安全。

应用层：本地语音助手“鸿小伴” + HarmonyOS App 联动

“鸿小伴”支持离线语音识别，语义解析与指令执行全部在本地完成，确保隐私安全；
与 HarmonyOS App 实现南北向架构连接，便于用户远程操控、状态查看、设备扩展。

我们的核心优势（对比竞品总结）

维度	市面产品（如小爱、天猫精灵）	我们的系统
语音控制	云端识别、联网依赖高	本地识别、断网可用、快且隐私
生态扩展	品牌封闭、协议复杂	MQTT通用协议、易拓展
特定人群适配	泛化模型、效果不稳定	方言优化、老人儿童适配
数据隐私	云处理、存在泄露风险	全本地部署、不上传敏感数据

在智能家居内卷化的大环境中，我们选择“轻量化本地智能+深度硬件融合+垂直场景适配”的差异化路径，针对性解决主流产品的三大痛点，真正做到安全、贴心、可落地。

团队在开发过程中遇到的最大技术挑战是什么？如何解决的？

技术挑战一：本地语音识别的实现

“我们这套系统的第一大难点，是如何在资源有限的Hi3861开发板上，实现高效且准确的本地语音识别。同时保证识别效果对老人、儿童等弱语音人群仍具备良好适配性。因为Hi3861板子CPU算力不高，内存也有限，传统的深度学习模型很难直接跑。同时离线语音识别易受噪声、方言、口音影响，尤其是老人和儿童的语音识别难度大。

我们的技术解决方案

我们从算法优化、特征提取、系统调度三个维度进行攻关：

离线模型精简与适配

我们选用轻量级神经网络，对开源语音识别模型进行剪枝与量化，使用关键词识别（KWS）+ 命令词识别（CMS）双阶段识别策略，既保证了系统资源可承载，又提升了识别准确率。

信号优化

并结合了梅尔频率倒谱系数（MFCC）等成熟的语音特征提取方法。同时，用汉明窗函数处理信号，进行端点检测，保证输入数据的质量。

实时性保障与资源管理

我们在LiteOS上通过中断优先级与任务管理优化语音识别任务实时调度，确保交互不卡顿、控制实时性强。

💡

面对算力受限和用户多样化的挑战，我们通过模型压缩、信号优化与LiteOS系统级调度，实现了在低功耗设备上稳定、高效、本地化的语音交互系统，这是我们项目的技术核心，也是我们区别于大厂产品的关键壁垒。

技术挑战二：多开发板间的协同通信

“第二个挑战是系统中我们用了两块开发板——Hi3861负责收集传输传感器数据，ESP32-S3则负责高算力任务如人脸识别，ASR-PRO开发板处理语音控制。为了让它们协同工作，我们设计了基于UART的通信协议。

数据传输采用轻量的JSON格式，方便解析和轻量级通信。同时加入了确认应答机制（ACK+超时重传），避免信息丢失。利用LiteOS的任务管理，进行串口驱动适配与任务隔离，避免资源冲突，实现了多线程并发，保障三块板子间的指令传递稳定。

技术挑战三：MQTT连接的安全与稳定

“再来说一下上云通信。我们的设备通过MQTT协议连接华为云的IoT平台。网络通信时常会遇到断连、数据被劫持等安全隐患。设备需要通过 MQTT 协议与华为云 IoTDA 平台保持长连接，且在断网重连、密钥认证等环节必须保证安全和稳定。

为此，我们使用 MQTT + TLS 双层加密机制，防止数据泄露与中间人攻击保证数据传输安全；

设计了心跳机制，确保设备掉线时能快速自动重连；

设备认证方面采用设备ID和预共享密钥双重验证，接入平台前进行安全校验。

再加上云平台的设备影子功能，保持设备和云端状态实时同步，整体通信既安全又稳定，断线后恢复时间小于3秒。”

技术挑战四：语音与环境数据的智能联动

“最后一个技术挑战是实现语音指令和环境传感器数据的智能融合。用户说‘太热了’或者‘空气不好’时，系统需要理解语义，并结合温湿度、烟雾等传感器实时数据，做出联动控制。’‘

我们构建了事件驱动模型，将语音输入、传感器数据、云端命令统一抽象为事件来处理。

利用队列机制缓存异步数据，确保处理顺序合理；

根据预定义的语义规则，控制规则的映射表。比如如“太热”→判断温度>28°C→打开窗帘+风扇；

通过消息队列管理多源异步信息，结合LiteOS的任务优先级调度，在LiteOS系统下，通过低优先级定时任务轮询环境状态，高优先级响应语音指令。

技术难点 → 对策 → 成果

如果华为云服务出现故障，系统如何保证正常运行？

“针对云服务可能出现的故障，我们设计了多层保障机制，确保系统依然可以稳定运行，保证用户基本功能不中断。

首先，在本地端，我们的核心控制逻辑和关键功能都实现了离线部署。例如语音识别、人脸识别及本地设备控制均在Hi3861和ESP32-S3两块开发板上完成，完全不依赖云端。即使云端连接中断，用户依然可以通过语音指令操控家居设备，实现智能联动。

其次，设备端采用本地缓存和状态同步机制。系统会将关键操作和设备状态缓存在本地，一旦云端恢复，自动与云端进行同步，避免数据丢失和状态错乱。

再者，针对远程控制和云端管理功能，如果云服务出现故障，设备会进入降级模式，停止与云端交互，但保持本地控制正常。用户也可以通过局域网内的App或直接语音控制完成基本操作。

人脸识别算法

对采集到的图像进行预处理

灰度图处理：将彩色图像转换为灰度图像，以实现在保留图像纹理等数据信息的同时提高计算效率。
噪声处理：图片中的噪声干扰会影响人脸识别的精度，常见的噪声有高斯噪声、泊松噪声、椒盐噪声等，一般采取高斯滤波来处理高斯噪声，采取中值滤波来处理椒盐噪声。

通过局部二值模式（LBP）提取人脸特征

LBP能够快速得到表示图像纹理特征的特征值。
LBP的基本步骤：

1.领域比较：对图像中的每个像素点，与其周围圆形邻域的像素进行比较，若邻域像素值大于中心像素值标记为1，否则标记为0。
2.将比较结果按固定顺序排列成一个二进制串，再转化为十进制数，作为中心像素的LBP值。
3.计算所有像素的LBP值后，统计这些值的直方图，形成最终的纹理向量。

为什么采用LBP算法

高效且易于实现1的纹理特征描述方法，计算简单，并且可以适应不同的光照环境。

使用OV2460高清摄像头，支持动态人脸跟踪与实时视频流显示

Micropython

micropython是python3编程语言的精简高效的实现，其中包括python标准库的一小部分，并且是经过优化，可在微控制器和受限环境中运行，可以在所支持的硬件平台上使用python语言对硬件控制。

使用的开发板型号：普中ESP32S3

为什么选用ESP32S3

核心优势在于无线通信+高性能+低功耗+低成本四者的平衡。

有丰富的外设外设接口：可直接连接传感器、执行器、显示屏等。

开发便捷：支持MicroPython，可以快速实现原型开发。

原生支持WIFI和蓝牙，无需额外购买无线模块。

RDIF射频卡模块

将射频卡贴近模块，便可检测到卡的UID和类型，系统识别UID号，若该卡片已录入，则开锁，若卡片未录入，则触发报警系统。

NFC碰一碰的实现原理

NFC是一种短距离无线通信技术，支持双向数据传输。实现碰一碰弹窗功能的核心是通过NFC标签和设备间的交互，触发手机端应用读取特定数据并展示信息。

在智能设备（如环境检测模块、智能照明面板）上嵌入NFC标签，标签中存储设备的唯一标识符。当支持NFC的手机靠近标签时，手机读取标签内容，读取设备中存储的相应参数，然后通过弹窗给用户进行直观的展示。

实现的步骤：

配置NFC标签

使用NFC读写工具，将设备以NDEF（NFC数据交换格式写入标签），存储设备的名称和参数。

手机端应用开发

在鸿蒙app中注册NFC前台分发系统，捕获手机靠近标签的事件。然后读取NDEF消息并提取设备标识符，最后调用系统弹窗展示设备信息。

NFC碰一碰功能的实际应用场景是什么？如何解决NFC卡片丢失的安全问题？

“碰一碰”功能主要用于快速获取环境数据（如温湿度）和设备状态（如窗帘开合），适合临时访客或紧急查看场景。

针对卡片丢失问题，我们采用动态密钥技术：每次开锁时需与云端验证卡片合法性，若卡片丢失，用户可通过APP远程注销该卡片权限，并重新绑定新卡。

NFC 碰一碰技术与 NFC 刷卡开门技术有什么区别

功能定位不同

碰一碰 NFC 系统的目的是提供便捷的设备交互与信息展示（如查看智能照明模块的信息、空调的信息等等）
门禁 NFC 系统的目的是实现安全身份认证与物理门锁控制，场景是通过 NFC 卡片或手机开锁、结合人脸识别双重认证。

技术实现

碰一碰 NFC 系统硬件模块采用的是被动 NFC 标签，通信方式是单向读取（手机读取标签信息），标签用于存储设备 ID 或触发指令。
门禁 NFC 系统采取的是双向认证（卡片与读卡器动态加密交互），硬件模块采用的是主动 NFC 模块。

为什么 NFC 门禁系统采取的是刷卡而不是刷手机？

1. 射频卡片是独立硬件，无联网功能，无法通过远程攻击篡改数据，安全性较高。

2. 卡片遵循 ISO 14443 标准，与 MFRC522 等通用读卡器完全兼容，无需适配不同手机型号的 NFC 协议差异。并且手机 NFC 功能依赖厂商开发底层 API，而嵌入式系统更易与 MFRC522模块直接通信，实现低延迟响应。

3. 门禁系统需在断网时仍能正常运行，射频卡片支持本地加密验证，而手机 NFC 通常依赖云端服务或 APP，断网时可能失效。

4. 适老化设计：老年人可能不熟悉手机操作，物理卡片“一贴即用” 更符合其使用习惯。

此外，卡片可设计为钥匙扣或手环形式，避免手机丢失导致无法进门的风险。

尽管当前系统以射频卡片为主，但未来可通过升级支持“双模认证”：同时支持手机 NFC 和射频卡片开锁。

未来我们将对硬件进行升级，将现有的 MFRC522 读卡器升级为支持 ISO 14443-4 的模块（如PN534），并且在手机端进行相应的功能开发，模拟虚拟卡片，创建动态密钥。

NFC 碰一碰模块的实际应用场景

一）设备快速配对与初始化：

场景：新设备首次接入家庭网络：

实现：用户将手机靠近设备的 NFC 标签，自动读取设备唯一标识符，触发 APP 自动完成 WIFI配置与账号绑定，无需手动输入密码或扫码。

优势：简化设备联网流程，降低用户操作门槛（尤其适合老年用户）；减少配网错误率，提升设备初始化效率。

二）设备状态实时查看：

场景：用户想快速了解空调滤网寿命或净水器水质。

实现：手机触碰设备 NFC 标签，直接弹窗显示滤网更换倒计时、水质 TDS 值等关键数值，并支持一键购买耗材。

优势：免去了打开多个 APP 查找信息的繁琐流程。

三）安全应急操作

场景：火灾、燃气泄露等紧急情况下需快速关闭危险源

实现：厨房设置“应急 NFC 点”，手机触碰后自动关闭燃气阀门、打开排气窗、触发声光报警。

四）老年人健康监护

场景：独居老人需快速联系子女或呼叫医疗救援。

实现：在床头、卫生间等关键区域部署 NFC 标签，老人手机触碰后自动发送定位与健康数据至紧急联系人，并启动语言通话。

优势：操作极简，避免老人因慌乱误触其他功能；并且支持离线触发。

五）能耗管理透明化

场景：用户希望了解家电实时能耗。

实现：手机触碰冰箱、洗衣机等设备的 NFC 标签，弹窗显示今日用电量、节能建议。

优势：支持与电费账单联动，提供个性化节能方案。

作品的设计意义是什么？

作品的设计重点是什么？

为什么选择这个主题进行创作本次作品？

主要运用了什么软件来实现？

Hi3861参数

CPU子系统

处理器：高性能32bit微处理器，最大工作频率160MHz。
存储：内嵌352KB SRAM、288KB ROM，以及2MB Flash。

计设PPT答辩稿子

各位评委老师大家好，下面将由我向大家汇报我们本次作品：睿启鸿居，基于openharmony的智能家居场景控制系统。

（跳三页）随着人们生活水平的提高，智能家居系统已经成为了构建良好居住环境的重要环节。如今的智能家居市场已具规模，但市面上的产品种类繁多，参差不齐，缺乏统一的标准和规范。其次，如何保证用户隐私和数据安全也是亟待解决的问题。

用户期望应用拥有智能控制中心、智能照明、安防系统、家庭环境监测等多个板块的功能。下面我们将介绍如何对其进行一一实现。【35s】

（跳两页）以下分别是该app登录、智能控制中心、智能照明、环境监测、系统扩展模块的界面。通过登录账号，用户可以进入app，并通过场景切换按钮实现多个家居和场景的智能控制。智能照明模块通过环形图实时显示室内光照，根据不同场景精准控制各个环境照明，同时具备提醒用户和智能控制的部分家居的功能。环境监测模块可检测环境参数，智能控制空调的开关，并提醒用户诸如火灾、收衣等事务。家居管理模块可使系统灵活接入其他家居电器。【35s】

普中开发板的Hi3861芯片，搭载了LiteOS，集成了高性能微处理器、硬件安全引擎以及丰富的外设接口，性能强大。MQ-2烟雾传感器性能稳定，灵敏度高，非常适合用于火灾的监测预警。DHT11温湿度传感器和单片机通讯,通过AO模拟输出引脚进行单总线传输.单片机连接光敏传感器进行ADC电压采样，通过计算得到当前光敏电阻阻值，进而计算出当前的光照强度值。雨滴传感器支持数字开关量输入输出，置于降雨环境中，当连续三次检测到雨量强度大于等于20mm每小时，判定为有效降雨。

系统接收到实时数据后，即可驱动各类型的硬件，如步进电机驱动的窗帘、无源蜂鸣器驱动的报警器等模块。【50s】

华为提供了强大的物联网平台:华为云LOT。本系统通过WIFI接入该平台，并使用MQTT协议，实现了平台和设备的双向消息通信。

系统和平台连接时，需获取设备的唯一标识，提供id、密钥及物联网平台的接入点信息。

我们选用ESP32-S3作为智能安防模块的系统主控。引入MFRC522射频卡模块，实现NFC门禁卡开锁功能。

装配薄膜晶体管液晶显示器，及OV2460摄像头模块，保证了人脸识别功能的稳定性。

除了进行灰度图处理、噪声处理，我们还采取了LBP算法，提高了人脸识别的速率和准确性。【45s】

接下来是我们的创新拓展板块。

为提高家居的智能性和便捷性，同时考虑到用户人物画像覆盖儿童和老人等不方便使用app的人群，我们设计了语音助手鸿小伴对所有家居进行语音控制。我们采用汉明窗函数处理信号、检测端点，采用梅尔频率倒谱函数对信号进行特征提取，大大提高了语音识别模块的稳定性。

我们为每个目标设备配备了符合标准的NFC标签芯片，当手机靠近模块时，应用会发送查询请求，同时通过RESTFUL API获取设备静态档案和实时运行数据，通过弹窗显示信息。我们采用了harmony os的分布式安全架构，保证了用户的信息安全。下面是我们的项目成果展示。【45s】

未来，我们将持续深耕可信计算与情感交互，以中国自主创新之力，助推智能家居从“万物互联”迈向“万物智联”，在数字中国的蓝图中，书写科技惠民的温暖注脚。【20s】

以上是我们本次项目的全部内容，感谢各位评委老师观看。