今年年初，一家做生鲜配送的物流公司找到我们。老板上来就倒苦水——"上个月又被食药监抽检了，两车货温度记录不全，罚了款不说，还丢了一个连锁超市的长期合同。"

这家公司在江苏，主要给周边几个城市的超市、餐厅配送生鲜食材。30多辆冷藏车，每天发车几十趟。但冷链监控一直是个头疼的问题：冰箱里贴的温湿度记录仪只能本地存数据，等卸货了才把U盘拔下来看，发现问题已经晚了。

这篇文章记录我们怎么用边缘AI网关+传感器给他们的冷链系统做了实时监控。不画大饼，只说做了什么、碰到什么坑、效果怎么样。

一、现场情况摸底

先跟着车队跑了三天，大概摸清了情况：

还有一个细节：司机是不太配合的。因为温度监控如果太严格，他们开关车门、中途停车都会被记录，所以司机有抵触心理。方案设计要把这个因素考虑进去。

二、方案设计

综合这些情况，方案分了三个层面：

采集层：每车部署温湿度传感器+车门传感器

每辆车装3样东西：

传感器的数据通过蓝牙低功耗协议传到车内的边缘AI网关。不用布线，安装方便。

边缘层：每车安装一台边缘AI网关

每辆车部署一个车载边缘AI网关，主要作用是：

选车载网关有几个特殊要求：要支持12V/24V车载电源、要能在-20°C到60°C环境下工作、不能太大（车厢里空间有限）。

云端层：监控看板+合规报告+告警推送

云端是一个轻量的Web系统，功能包括：

告警通过企业微信推送到三个角色：调度员（实时监控）、维修组（冷机故障）、品控主管（温度超标）。

关键设计取舍：
温度阈值没有做成死板的一刀切。冷冻和冷藏的温度要求不同，同一辆车间隔运冷冻和冷藏货品时，系统自动切换阈值。司机装货前在车载屏上点选货品类型即可。

三、实施过程

第一周：硬件安装和联调

34辆车分两批安装。第一批10辆车，安装加调试用了3天。第二批节奏快了，24辆车2天搞定。

安装阶段遇到的问题：

第二周到第三周：试运行和阈值调优

前两周只采集不告警，建立基线。这个阶段发现了一些问题：

教训：冷链温度监控不能只看温度绝对值，要结合"车门状态+时间段+货品类型"综合判断。否则正常的装货卸货操作也会触发大量误报，司机和调度员都受不了。

第四周：司机培训上线

这是整个项目里比较费劲的一环。司机普遍对"车上装监控"有抵触，觉得公司在盯着他们。我们在每个车队搞了半小时的培训，核心就讲三件事：

讲完后大部分司机接受了。有个开了十几年冷链的老师傅说："早该装这个了，以前冷机坏了全靠运气发现。"

四、实际效果

系统上线两个半月后，我们和客户一起做了复盘：

温度超标运输次数：下降了约70%
从平均每周8-12次降到每周3-4次。大多数超标发生在装货和卸货环节，通过优化流程（缩短开门时间、提前预冷车厢）解决了。
冷机故障提前发现：4次
其中2次是制冷剂泄漏（出风口温度异常升高），1次是压缩机异响，1次是冷凝器散热风扇故障。都通过提前调度换车避免了货物损失。
客户投诉率下降明显
超市和餐厅反馈的"收到货温度不对"的情况从每月约5-6起降到了0-1起。丢失的那份连锁超市合同，对方说如果早几个月有这个系统，可能不会换供应商。
合规检查一次性通过
系统自动生成的温控记录满足食药监要求，不再需要人工整理。以前每次检查要花2-3天翻记录，现在点一下导出就行了。

当然也有些不太好的方面。

数据流量费用比预想高：每辆车每30秒上报一次数据，加上GPS位置信息，一个月单车流量约1.5GB。34辆车加起来不少。后续优化了上报策略——行驶中每5分钟上报一次摘要，只有温度异常时才恢复到30秒高频上报，流量降了一半以上。

司机抵触没有完全消除：虽然大部分司机接受了，但有个别人觉得"被监视感"挥之不去。公司后来把司机评分和优秀司机奖金挂钩，评分高的司机每月多拿几百块奖金，态度缓和了不少。

五、遇到的技术问题

断网重连数据补传

冷库和地下车库信号差，很多趟运输有半小时到一小时处于断网状态。边缘网关虽然本地缓存了数据，但重连后补传的逻辑一开始有问题——如果补传数据量太大（断网1小时=120条记录×34辆车），服务器端压力很大。后来加了一个限速队列，每分钟补传量不超过50条，同时云端和本地做数据去重。

# 补传限速的简化逻辑
import time, queue

retransmit_queue = queue.Queue()
MAX_PER_MINUTE = 50

def enqueue_retransmit(data):
    retransmit_queue.put(data)

def retransmit_worker():
    count = 0
    start_time = time.time()
    while not retransmit_queue.empty():
        if count >= MAX_PER_MINUTE:
            elapsed = time.time() - start_time
            if elapsed < 60:
                time.sleep(60 - elapsed)
            count = 0
            start_time = time.time()
        data = retransmit_queue.get()
        send_to_cloud(data)
        count += 1

传感器漂移

运行了一个月后，有3个温度传感器的读数比其他传感器偏高了约1.5°C。排查发现是两个批次传感器质量不稳定。方案是加了自校验逻辑——每天早上冷机预冷到稳定温度后，对比同一车厢内前后两个传感器的读数差，如果偏差超过1°C就标记该传感器为"需校准"并通知运维。

告警疲劳

系统上线第一周，告警太频繁了。单个司机一趟运输能收到十几条告警——"车门打开""温度上升""车门关闭""温度下降"……很快就变成了"狼来了"。我们做了这几项优化：

六、个人的思考

做冷链这个项目之前，我一直以为冷链监控就是"装个温度探头+连个网"的事。做完之后感受完全不同。

真正的难点不是技术，是"人"。司机怕被监控、调度员怕误报过多看不过来、老板想知道能不能省钱……每个角色都有自己的担忧。技术方案必须把这些担忧考虑进去，否则再好的系统也用不起来。让司机看到这个系统能保护他们（冷机坏了警报他而不是追责他），比跟司机讲什么物联网架构有用得多。

合规需求是很好的切入场景。很多工厂、物流公司对数字化转型没有概念，但你要说"这个系统能帮你过食药监检查"，他们一下子就听进去了。中国的食品安全法越来越严格，冷链运输企业被罚的案例每年都有，这是实打实的痛点。

边缘计算在冷链场景下的价值很直接。全程温度数据必须在本地持久存储，不能因为4G信号不好就丢数据。而且实时告警必须在车辆本地判断——如果等数据传到云端再判断再推送到手机，中间延迟可能超过1分钟，对一些紧急情况来说太慢了。

数据合规报告是意外之喜。原本客户只想要温度监控，结果发现"一键导出合规报告"反而是他们日常使用频率较高的功能之一。这说明做B端产品有一个原则：帮客户省时间才是真价值，不要低估"省掉两三天手工整理工作"这件事的分量。

七、给你的建议

如果你也在搞冷链物流或者类似的IoT监控项目，几点个人经验：

  1. 先跑10辆车再铺开。传感器选型、网关安装位置、阈值设置这些东西不跑起来不知道有没有问题。10辆车的试运行至少留2周，把坑踩一遍再铺剩余的车
  2. 断网是常态不是异常。冷库、地下车库、山区道路……很多地方没信号。边缘缓存和补传是必备功能，不是可选项。而且一定要做好数据去重
  3. 告警阈值要分场景。运输途中的温度管控和装卸货时的温度管控标准不同，冷冻和冷藏的阈值不同。一刀切的告警规则只会产生海量误报
  4. 司机的感受很重要。如果司机觉得这个系统是"老板的摄像头"，他们会想方设法破坏（拔电源、遮挡传感器）。从设计上就要让他们觉得这个系统是在帮他们
  5. 合规报告是ROI亮点。不要只做技术监控，想办法把数据转化成监管需要的报告格式。在中国做冷链，满足食药监要求是刚需
  6. 选工业级传感器。冷链车厢的环境比想象中恶劣——震动、温差大、冷凝水。便宜的家用传感器撑不过两个月就漂移了