4、Edge AI基础：边缘计算概念、边缘设备（MCU、树莓派、Jetson等）、边缘与云端协同架构
在传感器数据异常检测项目中，数据并非总是需要上传到云端进行处理。随着物联网设备数量的爆发式增长，网络带宽、传输延迟、数据隐私和运营成本成为传统“端-云”架构难以回避的瓶颈。Edge AI（边缘人工智能）的核心思想，是将人工智能推理能力下沉到靠近数据源头的网络边缘侧，在本地完成数据采集、预处理、特征提取、模型推理甚至部分模型更新，从而实现对传感器异常的实时响应。本章将系统梳理边缘计算的核心概念、主流边缘硬件平台的选型逻辑，以及边缘与云端协同的工程架构，为后续章节中在具体设备上部署异常检测模型奠定基础。
上图展示了传感器数据异常检测场景下典型的边缘-云端协同架构。传感器层负责物理信号的采集，边缘计算节点承担实时推理与本地决策，云端则聚焦于模型训练、历史数据挖掘和全局策略优化。这种分层架构并非简单的“云替代边缘”，而是根据延迟、带宽、算力和功耗约束进行动态任务分配。理解这一架构，是选择合适边缘设备、设计高效异常检测流程的前提。
4.1 边缘计算核心概念与设计原理
边缘计算（Edge Computing）是一种分布式计算范式，它将计算、存储和网络资源从集中式数据中心下沉到网络边缘，即数据产生源附近。在传感器异常检测场景中，边缘计算并非仅仅为了“省流量”，其核心价值体现在三个维度：实时性（毫秒级响应，避免网络往返延迟）、可靠性（在断网或弱网环境下仍能维持本地监控）、隐私与安全（敏感数据不出厂区，降低泄露风险）。
从工程实现角度看，边缘AI系统通常包含以下关键模块：
- 数据接入层：负责与传感器接口对接，完成信号调理、模数转换（ADC）、协议解析（如Modbus、CAN、I2C）。
- 预处理引擎：执行去噪（低通滤波、中值滤波）、去趋势、重采样、时间窗口切片等操作，为特征提取提供干净的数据流。
- 特征工程模块：在边缘侧计算时域特征（均值、峰值、峭度）、频域特征（FFT频谱能量、边带幅值）或统计特征（标准差、均方根）。
- 推理引擎：运行经过压缩或量化的轻量级模型（如TinyML、TensorRT、ONNX Runtime），输出异常概率或分类标签。
- 决策与执行单元：根据推理结果触发本地告警、执行简单控制逻辑（如紧急停机），或仅将异常片段上传云端。
边缘计算的设计需要遵循“算力-功耗-成本”三角平衡原则。并非所有场景都需要GPU级别的算力，对于简单的阈值判断或单变量统计异常检测，一颗主频200MHz的MCU即可胜任；而对于多通道振动信号频谱分析或CNN模型推理，则需要更高算力的Linux板级设备或GPU模块。
4.2 主流边缘设备选型与对比
当前用于传感器异常检测的边缘设备主要分为三大类：MCU级、Linux板级和GPU边缘计算模块。它们各自拥有不同的适用边界，选型时需结合传感器数量、采样率、模型参数量和部署环境（如工业现场温度、供电条件）综合判断。
| 设备类型 | 代表型号 | 算力资源 | 功耗范围 | 典型应用场景 | 开发复杂度 |
|---|---|---|---|---|---|
| MCU | STM32H743、ESP32-S3 | 单核/双核 Cortex-M7/M4，主频 240-480MHz，无操作系统或RTOS | 0.1W - 0.5W | 电池供电的无线传感器节点、简单阈值判断、振动特征值计算 | 低（需要交叉编译，调试相对繁琐） |
| Linux 板级 | 树莓派4B/5、RK3588 | 4核 Cortex-A72/A76，主频 1.5-2.4GHz，内存 2-8GB，集成GPU | 3W - 10W | 多通道数据采集、Python生态快速原型、中等复杂度模型（随机森林、小型CNN） | 中（Linux环境，Python/C++均可） |
| GPU 边缘模块 | Jetson Orin Nano、Xavier NX | GPU 拥有 512-1024 个 CUDA 核心，支持 TensorRT 加速 | 5W - 25W（可调模式） | 高采样率振动信号频谱分析、深度学习模型（LSTM、Transformer）、多传感器融合 | 较高（需要CUDA环境配置，显存管理） |
在选型过程中，除了关注芯片参数，还需要评估外设接口丰富度（是否具备足够的UART、SPI、I2C、ADC通道）、工业级温度范围（-40℃~85℃）以及长期供货稳定性。例如，树莓派虽然生态丰富，但其商业级温度范围（0℃~50℃）限制了在户外或高温车间场景的应用，此时应优先考虑采用i.MX8或瑞萨RZ/G系列的工业级核心板。
4.3 边缘与云端协同架构模式
边缘与云端的协同并非简单的“数据上传-结果返回”，而是根据业务需求和数据特性，形成多种分工模式。在传感器异常检测项目中，常见的协同架构有三种：
- 端侧实时检测 + 云侧模型迭代：边缘设备运行轻量级模型进行实时推理，将检测到的异常样本（原始波形或特征向量）上传云端。云端利用这些难例样本进行模型重训练，定期更新边缘模型。该模式适合数据分布随时间漂移的场景（如设备老化）。
- 端侧全量处理 + 云侧全局分析：边缘设备完成所有数据清洗和异常判断，仅将告警事件和统计摘要（如每小时异常次数、频谱趋势）上报云端。云端负责多站点横向对比和长期趋势预测。该模式对带宽要求极低，适合跨地域部署。
- 云边协同推理：当边缘设备算力不足时，边缘侧先执行浅层特征提取和粗筛，将疑似异常片段压缩后上传云端，由云端高性能模型进行精确判定。该模式需要设计可靠的数据传输协议和断点续传机制。
无论采用哪种模式，都需要定义清晰的数据同步协议和模型版本管理机制。例如，边缘设备应记录当前模型版本号，云端下发新模型时采用灰度发布策略，先在少量节点验证效果，再全量推送。
4.4 实战场景：工业电机轴承异常检测的边缘部署
下面通过一个具体的工业场景，说明如何将边缘计算概念落地。某工厂需要对车间内20台大型电机的轴承状态进行实时监测，防止因轴承磨损导致非计划停机。每台电机安装2个加速度传感器（采样率25.6kHz）和1个温度传感器（采样率1Hz）。
初始目标与约束：要求系统在轴承出现早期损伤（如外圈点蚀）后2小时内发出告警；工厂网络不稳定，存在周期性断网；现场无IT人员，设备需支持远程运维。
方案设计过程：
- 边缘设备选型：由于需要处理25.6kHz的振动数据并进行FFT频谱分析，MCU算力不足，故选用Jetson Orin Nano（8GB版本），每台设备接入2台电机的传感器（共6通道）。
- 边缘侧处理流程：使用Python编写采集程序，通过I2C读取加速度数据，每秒钟计算一次加速度信号的均方根值（RMS）和频带能量（1kHz-5kHz）。将原始波形暂存于本地NVMe SSD，仅当RMS超过设定阈值或频带能量异常时，才将前后各5秒的原始波形打包上传。
- 云端协同：云端部署TensorFlow Serving，接收边缘上传的异常波形，使用预训练的1D-CNN模型进行精确分类（正常/内圈故障/外圈故障/滚动体故障）。云端每周根据新收集的样本重新训练模型，并通过OTA方式更新边缘设备上的TensorRT引擎。
- 断网策略：边缘设备内置SQLite数据库，缓存未上传的异常样本。当检测到网络恢复时，按时间顺序自动补传，并记录上传状态。
结果与复盘：系统上线后，成功在3次轴承故障早期发出告警，避免了设备损坏。实际运行中发现，边缘设备CPU占用率约45%，GPU占用率约30%，功耗约12W，在可接受范围内。复盘时发现，最初设计的固定阈值（RMS>0.5g）在低速重载工况下存在误报，后改为“自适应阈值”（基于过去24小时数据的滑动平均），误报率降低了80%。
4.5 常见误区与设计复盘
在边缘AI系统设计中，工程师常陷入以下误区，需要特别警惕：
- 误区一：将云端模型直接部署到边缘。云端模型通常参数量大、计算量大，直接部署会导致延迟超标或内存溢出。正确做法是进行模型剪枝、权重量化（INT8）和算子融合，并使用TensorRT或TFLite进行优化。
- 误区二：忽略数据采集的同步性。在多传感器融合场景中，如果各通道采样时钟不同步，会导致特征错位。应使用硬件触发或PTP时间同步协议，确保各通道数据时间戳一致。
- 误区三：边缘设备“大材小用”或“小马拉大车”。在只做温度阈值判断的场景中使用Jetson，不仅浪费算力，还带来散热问题；而在需要处理高帧率图像时使用树莓派，则会导致严重丢帧。
- 误区四：缺乏模型回退机制。当云端下发的新模型在边缘设备上表现异常（如误报率飙升），应能快速回滚至上一版本。建议在边缘设备中保留最近两个版本的模型文件，并设置自动回滚触发条件。