边缘计算要解决什么问题
物联网早期架构很统一:设备负责采集,数据全部上传云端,云端负责存储、计算和决策。这套架构在设备数量少、数据量小的时候完全够用。但当产线上有上千个测点、每秒产生上万条数据时,问题就出现了——带宽成本按流量计费、云端往返延迟动辄上百毫秒、网络一旦中断整条产线就失去决策能力。
边缘计算不是“把云缩小放到现场”,而是把计算放到离数据最近的地方:能在本地闭环的决策就不要上云,能压缩成结论的数据就不要传原始流。
它真正带来的变化有三个:延迟从“秒级”降到“毫秒级”,因为决策不再跨公网;带宽从“原始数据量”降到“结论量”,因为网关先把数据聚合、过滤、压缩;可用性从“依赖网络”变成“断网自治”,本地闭环仍然工作,网络恢复后只补传结论与关键片段。
云边端三层职责
划分职责是边缘项目最容易出错的地方:把该在本地做的判断放到了云上,或者把本该集中管理的数据散落在现场的网关里。可以参考下面这张职责表。
| 层级 | 典型职责 | 延迟要求 | 数据留存 |
|---|---|---|---|
| 端(设备) | 采集、本地控制、安全联锁 | 毫秒级,硬实时 | 极短,通常只有环形缓冲 |
| 边(网关) | 协议转换、数据清洗聚合、规则判断、轻量推理、断网缓存 | 十毫秒到秒级 | 数小时到数天 |
| 云(平台) | 全局存储、跨站点分析、模型训练、设备管理与 OTA | 秒级到分钟级 | 长期,可追溯 |
一个判断标准很好用:如果这个逻辑在断网时必须继续工作,它就应该放在端或边;如果这个逻辑需要跨设备、跨站点才能算出来,它就应该放在云上。按这个标准切分,边界通常会自然浮现。
边缘网关的形态
“边缘”落地时是一台具体的机器,形态差异很大,选型时按算力需求分三档。
- 协议网关型:算力最低,主要工作是协议转换(Modbus/OPC UA 转 MQTT)与数据转发,常见于设备替换成本高的老旧产线。
- 通用计算型:x86 或 ARM 多核,能跑容器与数据库,适合做规则引擎、边缘缓存、轻量视觉处理。
- 带 NPU 的推理型:如集成 NPU 的 ARM SoC,可以在本地跑量化后的视觉或振动模型,适合质检、预测性维护这类需要模型推理的场景。
- 容器化现场设备一旦到手就难得再动,用容器打包应用能让升级与回滚变成一条命令。
- 本地消息总线网关内部用一个 MQTT Broker 串联采集、处理、上报三类进程,比进程间直接调用更容易排查。
- 统一配置来源采集点表、规则、上报周期都从云端下发,避免现场改配置。
- 只读系统盘现场环境断电频繁,把运行数据写在外挂存储并做好掉电保护,能显著降低返修率。
边缘侧的数据处理与规则判断
边缘最直接的价值是“把原始流变成结论”。下面这段例子把 200ms 的高频采样在本地压成每秒一条统计结果,并只在越限时立即上报。
import json, time
from collections import defaultdict
class EdgeAggregator:
"""本地聚合 + 越限即时上报"""
def __init__(self, window=1.0, hi=85.0, lo=5.0):
self.window, self.hi, self.lo = window, hi, lo
self.buf = defaultdict(list)
self.start = time.time()
def feed(self, tag, ts, value):
self.buf[tag].append((ts, value))
# 越限:不走聚合,立刻上报,保证告警时效
if value > self.hi or value < self.lo:
self.emit_alarm(tag, ts, value)
if ts - self.start >= self.window:
self.flush(ts)
def emit_alarm(self, tag, ts, v):
print("ALARM", json.dumps({"tag": tag, "ts": ts, "v": v, "level": "high" if v > self.hi else "low"}))
def flush(self, ts):
out = []
for tag, pts in self.buf.items():
vs = [v for _, v in pts]
out.append({"tag": tag, "n": len(vs), "avg": round(sum(vs) / len(vs), 2),
"max": max(vs), "min": min(vs)})
if out:
print("UPLOAD", json.dumps({"ts": ts, "points": out}, ensure_ascii=False))
self.buf.clear()
self.start = ts
这段逻辑把数据量压缩了一到两个数量级:现场每秒 5 次采样,上云每秒 1 条统计;而真正重要的越限事件反而比原来更快送达。这就是“能压缩成结论的数据就不要传原始流”的具体含义。
边缘推理:模型怎么落到网关上
带 NPU 的网关越来越多,但把训练好的模型搬上去并不只是复制文件。核心问题是资源约束:内存小、算力有限、往往没有 GPU。常见的做法是先量化再部署,INT8 量化通常能把模型体积压到原来的四分之一,推理速度提升数倍,而精度损失通常可以接受。
# 边缘推理示例:ONNX Runtime(CPU/NPU 后端)
import numpy as np, onnxruntime as ort
sess = ort.InferenceSession(
"models/vibration_int8.onnx",
providers=["CPUExecutionProvider"] # 有 NPU 时换成厂商 EP
)
input_name = sess.get_inputs()[0].name
def predict(feature_vec):
x = np.asarray([feature_vec], dtype=np.float32) # 形如 (1, 1024)
logits = sess.run(None, {input_name: x})[0]
prob = float(1 / (1 + np.exp(-logits[0][0]))) # 二分类:异常概率
return prob
# 现场侧只上报结论,不上传原始波形
prob = predict(load_vibration_frame())
if prob > 0.85:
publish("site/jjy/edge/gw-01/alert",
{"level": "warn", "type": "bearing", "prob": round(prob, 3)})
- 训练在云、推理在边数据分布会漂移,模型需要定期用新数据重训再下发,版本管理必须提前设计。
- 给推理留余量现场算力要按峰值估算,占用长期超过 70% 会拖慢采集主流程。
- 可回退新模型上线必须支持一键回滚到上一版本,否则一次错误升级会停掉整个质检工位。
- 解释性输出只给一个概率,产线人员不会采信;同时输出关键特征或置信区间,才容易被接受。
云边协同:下发、升级与回传
边缘节点不是孤岛,它需要接受云端管理,也必须在断网时保持自治。行业里通用的做法是“设备影子”:云端保存一份期望状态,边缘侧上报一份实际状态,两者不一致时触发同步。
# 简化的影子同步:期望状态 vs 实际状态
DESIRED = { # 云端下发
"report_interval": 30,
"rules": [{"tag": "temp", "op": ">", "value": 80, "action": "alarm"}],
"model_version": "v1.4.2",
"collect": {"tags": ["temp", "vib", "current"], "freq_ms": 200}
}
REPORTED = { # 边缘侧实际生效
"report_interval": 30,
"model_version": "v1.3.0",
"online": True,
"buffered": 1284 # 断网期间缓存的上报条数
}
def sync(desired, reported):
todo = []
if desired["model_version"] != reported["model_version"]:
todo.append(("pull_model", desired["model_version"]))
if desired["report_interval"] != reported["report_interval"]:
todo.append(("set_interval", desired["report_interval"]))
return todo
print(sync(DESIRED, REPORTED))
断网时的处理原则可以概括成三条:本地闭环继续执行;结论数据写入本地持久化队列并带上采集时间;网络恢复后按时间顺序补传,并优先补传告警类事件。补传一定要限速,否则恢复瞬间的洪峰会把云端接口打挂。
什么时候值得上边缘
边缘不是必选项,它带来的是复杂度:多了一批需要运维的现场设备、多了一套需要同步的配置与模型。判断是否值得,可以对照下面这张表。
| 场景特征 | 是否适合边缘 | 理由 |
|---|---|---|
| 控制闭环要求毫秒级响应 | 适合 | 跨公网的云决策无法满足确定性延迟 |
| 单点数据量大(视频、振动) | 适合 | 原始流上传的带宽与存储成本过高 |
| 现场网络不稳定或按流量计费 | 适合 | 断网自治与本地聚合能直接省成本 |
| 设备数量少、采样低频 | 不必 | 直接上云的复杂度与成本都更低 |
| 纯统计报表类需求 | 不必 | 云端数据库与分析工具更成熟 |
| 数据合规要求不出厂区 | 适合 | 边缘侧完成脱敏与聚合,原始数据留本地 |
最后一条经验来自实践:先做“协议网关 + 本地聚合”这一档,把数据链路和运维体系跑顺,再考虑上推理。跳过第一步直接做边缘 AI,通常会把大量时间消耗在现场运维而不是算法效果上。