📚 课程目录第3章系统架构

3、系统架构：端侧、边缘侧、云端的典型分层架构，以及各层在日志链路中的职责

在Edge AI远程诊断场景中，日志采集链路并非简单的“设备上传文件”，而是一个跨越端侧（Edge Device）、边缘侧（Edge Gateway/Node）、云端（Cloud Platform）的三层协同体系。每一层承担着不同的计算、存储、网络与安全职责，且日志数据的形态、粒度、时效性要求也随层级递进而发生显著变化。理解这一分层架构，是设计可靠、低延迟、可扩展的远程诊断系统的基础。本章将系统拆解三层架构的职责边界、日志流转路径、关键设计约束，并结合工业现场的实际案例，剖析常见的设计误区。

上图展示了Edge AI远程诊断日志链路的典型三层架构。端侧负责原始数据的产生与初步处理，边缘侧承担区域汇聚与实时响应，云端则进行深度分析与全局模型迭代。三层之间通过不同的网络协议衔接，形成“数据上行、模型下行”的闭环。下面我们将逐层深入分析其职责与设计要点。

3.1 端侧（Edge Device）：数据源头与第一道防线

核心原理：端侧是日志的“生产者”与“守门员”

端侧通常指部署在工业现场或设备内部的嵌入式系统、传感器节点、工业控制器（PLC）或智能终端。在日志链路中，端侧的首要职责是产生原始日志，包括设备运行状态、温度/振动/电流等时序数据、故障报警、操作记录等。但端侧并非简单地将所有数据一股脑上传，它需要承担“第一道防线”的角色：数据清洗、格式标准化、本地缓存与初步异常检测。由于端侧计算资源（CPU、内存）和存储空间有限，且网络连接可能不稳定，端侧设计必须遵循“最小化传输、最大化本地价值”的原则。

  关键设计约束：端侧日志采集Agent应具备断点续传能力，使用环形缓冲区（Ring Buffer）存储最近N小时的日志，防止存储写满导致系统崩溃。同时，Agent需支持配置远程更新，以便在不升级固件的情况下调整采集策略。

判断方法：端侧日志质量评估指标

采集完整性：是否有丢失采样？可通过序列号或时间戳连续性校验。
时间同步精度：端侧设备时钟是否与NTP服务器同步？偏差超过100ms可能导致多源数据无法关联。
本地预处理有效性：异常初筛的误报率/漏报率是否在可接受范围？
资源占用率：日志采集进程的CPU占用是否超过5%？内存占用是否稳定？

案例拆解：注塑机温度传感器的日志采集优化

某注塑工厂的200台注塑机均配备温度传感器，每台设备每秒产生10个温度点。若全部原始数据直接上传，每日数据量将超过170GB，网络带宽与云端存储成本极高。我们为端侧设计了如下方案：

本地特征提取：在端侧MCU上运行轻量级算法，每10秒计算温度均值、标准差、变化率，仅上传这些统计特征（约1KB/10s），原始数据仅保留在本地SD卡中（保留48小时）。
异常触发上传：当温度变化率超过阈值（如5°C/s）或绝对值超限时，立即上传前后各30秒的原始波形数据，用于云端精确诊断。
结果对比：优化后每日上传数据量降至约1.7GB，减少99%。同时，由于异常数据被完整保留，云端诊断准确率从82%提升至94%。

风险提示：端侧特征提取可能丢失关键细节。务必在本地保留原始数据至少24小时，以便事后回溯。同时，特征提取算法需定期用云端标注数据回测，防止“特征漂移”。

3.2 边缘侧（Edge Gateway）：区域汇聚与实时响应中枢

核心原理：边缘侧是连接端侧与云端的“桥梁”与“缓冲器”

边缘侧通常部署在工厂车间或园区机房，以边缘服务器、工业网关或边缘计算节点的形式存在。它汇聚多个端侧设备的数据，执行协议转换、数据聚合、流式分析、本地存储与实时控制。边缘侧的核心价值在于：即使云端网络中断，本地诊断与决策仍可继续运行，保障生产安全。同时，边缘侧可大幅降低云端数据压力，只上传“有价值”的日志或聚合结果。

功能模块	技术选型	职责说明
协议接入	MQTT Broker, OPC UA Server, Modbus TCP	统一不同厂商设备的通信协议，屏蔽底层差异
流式处理	Apache Flink, Node-RED, 自研C++引擎	实时过滤、去重、窗口聚合、规则触发
边缘存储	InfluxDB, SQLite, 本地文件系统	保存最近7-30天的原始或预处理日志，支持快速查询
AI推理	TensorFlow Lite, ONNX Runtime	运行故障分类模型，实现毫秒级本地告警

操作流程：边缘侧日志链路搭建步骤

设备发现与注册：自动发现网段内的端侧设备，获取其设备ID、能力描述。
数据接入配置：为每种设备类型配置解析规则（如JSON Schema、二进制报文格式）。
流式任务编排：通过可视化界面定义“数据源→过滤条件→聚合窗口→输出目标”的流水线。
上行同步策略：设置数据上传优先级（实时告警>统计摘要>原始日志），并配置带宽限速。
健康自检：边缘节点定期向云端发送心跳，报告自身CPU、内存、磁盘余量。

经验提醒：边缘侧务必部署本地消息队列（如EMQX或Mosquitto），即使云端Kafka不可用，边缘侧数据也不会丢失。建议采用“边缘存储+定期批量补传”策略，确保数据最终一致性。

3.3 云端（Cloud Platform）：全局分析与模型迭代大脑

核心原理：云端负责长期存储、深度挖掘与知识沉淀

云端是日志链路的最终汇聚点，承担海量数据持久化、多维度关联分析、AI模型训练与迭代、跨工厂/跨设备对比等任务。云端不追求毫秒级响应，而是注重数据处理的深度与广度。通过云端分析，可以发现单台设备无法暴露的共性问题（如某批次传感器的批量故障），并持续优化边缘侧与端侧的AI模型，形成“数据飞轮”效应。

判断方法：云端日志架构健康度检查清单

数据延迟：从端侧产生到云端可查询，端到端延迟是否小于5分钟？
数据完整性：云端数据量与边缘侧上传记录是否一致？是否存在静默丢失？
存储成本：冷数据（超过90天）是否已转储至廉价存储（如S3 Glacier）？
模型迭代周期：从数据标注到新模型上线，周期是否小于2周？

案例拆解：风电场的跨机组故障模式识别

某风电场运营商管理着5个风场共300台风机。每台风机通过边缘网关上传振动、转速、功率等日志。云端团队利用历史数据训练了一个异常检测模型，但发现模型在A风场表现良好，在B风场误报率却很高。分析后发现：A风场地形平坦，B风场地处丘陵，湍流强度不同导致振动基线偏移。云端通过引入“风场环境特征”作为模型输入，并利用联邦学习让每个风场在本地微调模型，最终将整体误报率从18%降至6%。

  云端设计要点：采用Lambda架构（批处理+流处理）处理日志数据。流处理层（如Flink）负责实时告警与指标计算，批处理层（如Spark）负责每日全量重算与报表生成。数据存储建议使用时序数据库（如TDengine）存储指标数据，用对象存储存储原始日志文件，用关系型数据库存储设备元数据与告警记录。

3.4 三层协同的关键机制与常见误区

核心原理：数据“上行”与模型“下行”的闭环

三层架构并非孤立存在，而是通过两条关键链路协同工作：数据上行链路（端侧→边缘侧→云端）与控制/模型下行链路（云端→边缘侧→端侧）。下行链路通常采用OTA（Over-The-Air）方式，将更新后的AI模型参数、日志采集策略、告警阈值下发至边缘侧与端侧。这一闭环使得系统具备自进化能力。

常见误区与规避策略

误区	后果	正确做法
所有日志都上传云端	带宽耗尽、存储成本飙升、实时性差	边缘侧执行“数据降维”，只上传特征与异常片段
端侧不做任何处理	无效数据占用网络，云端分析负担重	端侧至少完成时间戳校准、单位换算、基础滤波
边缘侧与云端模型不一致	边缘侧告警与云端结论矛盾，运维困惑	建立模型版本管理，边缘侧必须记录模型版本号
忽略端侧时钟同步	多源数据时间轴错乱，无法关联分析	部署NTP服务，或利用GPS/北斗授时

重要提醒：在边缘侧与云端之间，务必设计“数据回放”机制。当云端分析发现某次故障与边缘侧上传的特征数据不符时，能够向边缘侧发起“原始数据补传请求”，边缘侧从本地存储中提取对应时间段的原始日志重新上传。这是保障诊断准确性的最后一道保险。

总结复盘：三层架构设计自检表

端侧是否具备断网续传能力？本地缓存是否足够支撑至少24小时？
边缘侧是否实现了协议标准化？是否具备本地规则引擎？
云端是否区分了热数据、温数据、冷数据的存储策略？
三层之间的数据模型（字段定义、单位、枚举值）是否统一？
是否建立了从云端到端侧的模型/策略下发通道？

通过以上对端侧、边缘侧、云端职责的清晰界定与协同机制的设计，Edge AI远程诊断系统才能实现“实时感知、快速响应、深度洞察”的目标。下一层级的细节设计（如具体日志格式定义、传输协议选型）将在此基础上展开。