边缘计算要解决什么问题

物联网早期架构很统一:设备负责采集,数据全部上传云端,云端负责存储、计算和决策。这套架构在设备数量少、数据量小的时候完全够用。但当产线上有上千个测点、每秒产生上万条数据时,问题就出现了——带宽成本按流量计费、云端往返延迟动辄上百毫秒、网络一旦中断整条产线就失去决策能力。

边缘计算不是“把云缩小放到现场”,而是把计算放到离数据最近的地方:能在本地闭环的决策就不要上云,能压缩成结论的数据就不要传原始流。
边缘计算配图:云端、边缘网关与末端设备的三层结构
云边端不是三套孤立的系统,而是同一条数据链路上三种不同的处理职责

它真正带来的变化有三个:延迟从“秒级”降到“毫秒级”,因为决策不再跨公网;带宽从“原始数据量”降到“结论量”,因为网关先把数据聚合、过滤、压缩;可用性从“依赖网络”变成“断网自治”,本地闭环仍然工作,网络恢复后只补传结论与关键片段。

云边端三层职责

划分职责是边缘项目最容易出错的地方:把该在本地做的判断放到了云上,或者把本该集中管理的数据散落在现场的网关里。可以参考下面这张职责表。

层级典型职责延迟要求数据留存
端(设备)采集、本地控制、安全联锁毫秒级,硬实时极短,通常只有环形缓冲
边(网关)协议转换、数据清洗聚合、规则判断、轻量推理、断网缓存十毫秒到秒级数小时到数天
云(平台)全局存储、跨站点分析、模型训练、设备管理与 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% 会拖慢采集主流程。
  • 可回退新模型上线必须支持一键回滚到上一版本,否则一次错误升级会停掉整个质检工位。
  • 解释性输出只给一个概率,产线人员不会采信;同时输出关键特征或置信区间,才容易被接受。