2. 系统总体架构设计：感知层、网络层、应用层三层架构详解
好，咱们直接进入正题。做智能垃圾桶满溢检测，第一步不是画电路板，也不是写代码。而是先把整个系统的骨架搭起来。我习惯把这套架构分成三层：感知层、网络层、应用层。说白了，就是「怎么采集数据」、「怎么传数据」、「怎么用数据」。
你想想看，一个垃圾桶要自己报告「我满了」，它得先知道自己满了对吧？这就是感知层的事。然后它得把这个消息告诉后台，这就是网络层。最后后台得有人看、有报警、有统计，这就是应用层。这三层缺一不可。
核心原则：每一层只做自己的事，层与层之间通过标准接口通信。这样做的好处是——哪一层出了问题，只改那一层就行，不用动整个系统。
2.1 感知层：垃圾桶的「五官」
感知层是离垃圾桶最近的一层。它的任务就两个：感知 + 控制。
感知，就是检测桶内垃圾的高度。我常用的方案是超声波测距模块，比如 HC-SR04 或者更工业化的 JSN-SR04T。为什么选超声波？因为红外容易受阳光干扰，激光成本高，超声波在垃圾桶这种封闭环境里反而很稳定。
控制，就是当检测到满溢时，要么本地报警（蜂鸣器响一下），要么把数据打包发出去。这里我建议用 LoRa 模块来做无线传输，比如 SX1278 或者 ASR6501。LoRa 的好处是功耗低、距离远，一个垃圾桶装两节干电池能跑一年。
嗯，这里要注意一个坑。我曾经在一个项目中，直接把超声波模块贴在垃圾桶内壁，结果测出来的数据全是乱的。后来才发现，超声波在桶壁之间来回反射，产生了多次回波。解决办法是：安装时让探头稍微倾斜 10-15 度，或者加一个喇叭口状的导波管。
避坑指南：我曾经在南方某城市的项目中，垃圾桶放在户外，夏天温度高达 45°C，超声波模块的测距误差直接飙到 10% 以上。后来我换用了带温度补偿的模块，问题才解决。所以选型时一定要看工作温度范围。
感知层的硬件清单大致如下：
| 组件 | 型号推荐 | 作用 |
|---|---|---|
| 主控 MCU | STM32L0 系列 / ESP32 | 处理数据、控制外设 |
| 超声波模块 | JSN-SR04T（防水型） | 测量垃圾高度 |
| LoRa 模块 | SX1278 / ASR6501 | 无线数据传输 |
| 电源 | 18650 锂电池 + 升压电路 | 供电，续航 6-12 个月 |
| 传感器 | DS18B20（可选） | 温度补偿用 |
2.2 网络层：数据怎么「飞」到服务器
感知层采集到了数据，比如「当前垃圾高度 85%」。接下来怎么办？得传出去。
网络层就是干这个的。它负责把每个垃圾桶的数据，通过 LoRa 网关汇聚，再转发到云平台。这里我画一条数据流给你看：
垃圾桶节点 → LoRa 网关 → 4G/以太网 → 云服务器（MQTT Broker）为什么中间要加一个 LoRa 网关？因为 LoRa 是星型网络，所有节点都直接跟网关通信。网关负责把 LoRa 的无线信号转成 TCP/IP 协议，然后通过 4G 或者网线发到云端。
我个人习惯在网关上跑一个轻量级的 MQTT 客户端。为什么选 MQTT？因为它协议轻、支持 QoS 等级、而且有遗嘱消息机制。万一网关掉线了，服务器能第一时间知道。
注意：LoRa 的通信频率在不同国家不一样。中国用的是 470-510MHz，欧洲是 868MHz，美国是 915MHz。买模块的时候一定要确认频段，不然就是违法的。我曾经有个学生买了 868MHz 的模块在国内用，结果根本连不上网关。
网络层的核心参数配置，我一般这样设：
- 扩频因子（SF）：SF7 到 SF12。SF7 速度快但距离短，SF12 速度慢但距离远。垃圾桶一般用 SF9 或 SF10，兼顾距离和速率。
- 带宽（BW）：125kHz 或 250kHz。125kHz 灵敏度高，适合远距离。
- 编码率（CR）：4/5。这个值越高抗干扰越强，但有效数据率会降低。
你可能会问：一个网关能带多少个垃圾桶？我实测过，在 SF10、125kHz 的条件下，一个网关理论上能带 200-300 个节点。但实际项目中，考虑到数据上报频率（比如每 10 分钟上报一次），带 100 个节点是比较稳妥的。
2.3 应用层：数据变成「决策」
数据到了云端，不能光存着。得让它产生价值。应用层就是做这个的。
应用层通常包含三个部分：
- 数据存储：用 InfluxDB 这类时序数据库，存每个垃圾桶的历史数据。
- 业务逻辑：判断满溢阈值、生成报警、调度清运车辆。
- 可视化展示：给环卫工人或者管理人员看的仪表盘。
举个例子。当某个垃圾桶的满溢度连续三次超过 90%，系统自动生成一个工单，推送到最近的清运车司机的手机上。这就是典型的业务流程。
我记得在做一个智慧园区的项目时，甲方要求「垃圾桶满了之后 30 分钟内必须有人处理」。我就在应用层加了一个定时器：如果满溢报警发出后 30 分钟还没收到清运确认，就自动升级报警，通知主管。这个功能后来被甲方夸了好几次。
数据流总结：
感知层采集 → 网络层传输 → 应用层处理 → 业务层响应
整个流程是单向的，但应用层可以下发指令（比如远程校准传感器），这就是双向通信了。
2.4 业务流程设计：从「满」到「清」的闭环
光有架构还不够，得把业务流程跑通。我设计了一个典型的闭环流程：
1. 垃圾桶节点每 10 分钟上报一次满溢度
2. 云端收到数据，存入时序数据库
3. 判断满溢度是否 ≥ 90%
├─ 否：继续等待下一次上报
└─ 是：生成满溢报警，推送到调度系统
4. 调度系统根据 GPS 位置，分配最近的清运车
5. 清运车司机收到工单，前往清理
6. 清理完成后，司机在 APP 上确认
7. 系统更新垃圾桶状态，关闭报警这个流程看起来简单，但实际落地时有很多细节。比如：
- 如果垃圾桶在 30 分钟内没有被清理，系统应该怎么办？我建议做二次报警。
- 如果某个垃圾桶连续 3 次上报 100% 满溢，但实际去看是空的，那可能是传感器故障。这时候应该触发设备维护工单。
- 数据上报频率不能太快，否则电池扛不住。也不能太慢，否则满溢了都不知道。10 分钟一次是我觉得比较平衡的值。
一个小技巧：我习惯在垃圾桶节点上做一个「动态上报间隔」。比如平时 10 分钟一次，当满溢度超过 80% 时，自动缩短到 5 分钟一次。这样既省电，又能及时捕捉到满溢时刻。
好了，这一章的内容就到这里。总结一下：三层架构各司其职，感知层负责「看」，网络层负责「传」，应用层负责「想」。业务流程则是把这些串起来，形成一个完整的闭环。下一章我会带你具体看硬件选型和电路设计，到时候咱们再细聊。
公众号:蓝海资料掘金营，微信deep3321