化工园区WSN泄漏监测：Ad-hoc组网与扩散预警

简介：围绕无线传感器网络在化工园区环境监测中的落地案例，这份文档面向物联网、环境工程及安全生产信息化方向的学习者与技术人员，帮助梳理如何借助 WSN 实时测控污染指标、提升园区安全监管与事故应急能力。内容按需求分析、系统组成、监测终端、中继站、监控软件和 Ad-hoc 组网展开，结合 RAE systems 气体传感器，说明终端可搭载 1—5 个传感器、GPS 与 JRc1 无线模块，中继站以太阳能供电覆盖 3—5 公里半径，监控软件则用于危化品扩散范围预测、事故影响分析与报告图表输出。压缩包共 1 个 doc 文件，约 15KB，篇幅精炼，便于快速把握案例框架。已有 849 人学习下载，可作为课程设计、方案调研或园区安全监测项目的前期参考资料，读者能从中了解系统数据流转、Ad-hoc 网络自动组网与自动重建思路，以及无线部署降低布线成本的实际价值。

1. 化工园区的监测需求，为什么最后没走有线方案

某化工园区的管委会要在大约十几平方公里的范围里，盯住上百个有可能泄漏的点位，最初的想法很直接：沿管廊拉一圈有线采集线，数据稳定，供电也简单。现场量完才发现，罐区之间挖沟要审批，管廊不允许随便开孔，跨主干道的线缆更是碰不得，光布线预算就顶掉整个项目一半，方案只能转向无线传感器网络（WSN）。这套化工园区环境监测系统由三部分组成：带 1 到 5 路气体传感器、GPS 与电池的终端节点，靠太阳能供电的无线中继站，以及内置扩散预测模型的监控中心。它要解决的是事前预警、事发定位、事后追溯三件事。下面这套结构，适合正在做 WSN 方向毕设的学生，也适合要给园区出一份可交付监测方案的从业者。

2. 需求拆解：四类监测指标与三个硬约束怎么落到选型上

2.1 三类使用者，诉求完全不一样

同一套系统，坐在不同位置上的人关心的东西差得很远。管委会安监口关心的是「有没有异常、异常在哪、我要不要现在打电话」，关注点是告警的时效性和准确率；园区内企业关心自己厂界那一圈的浓度曲线，需要能导出报表、能对上自家台账；应急救援人员关心的是到场之后还能不能进、哪个方向是下风口，要的是空间分布和扩散趋势，而不是某一点的历史曲线。

如果只做一套「浓度超标就报警」的逻辑，这三类人谁都用不顺。通常的做法是把数据分三层用：原始帧落库，保证事后可追溯；分钟级的统计值推到看板，给企业做报表；超过阈值的告警事件单独成表，附上位置、时间、当时风向，推给安监和应急。数据是同一份，视图是三份。这个拆分在需求阶段就要定下来，等到写监控软件时再回头改表结构，返工量非常大。

另一个容易被忽略的角色是运维。终端节点装在罐区高处，一年可能只上去两次，所以现场必须做到「装上去就不用管」：电池要能撑过一个完整的大修周期，中继站不能依赖市电，节点故障要能自己上报。很多方案在演示环境跑得很好，一进入长期无人值守场景就掉线，问题几乎都出在这一层。

2.2 监测三要素：浓度、位置、时间，缺一不可

气体传感器给出的只是一个浓度数值，单独看意义有限。同样 20 ppm 的读数，出现在罐区下风向 50 米和出现在办公楼下风向 2 公里，是完全两种处置方式。所以终端节点在设计时就绑定三件事：通道数据、GPS 坐标、采集时间戳，三者打包进同一帧。

终端侧可装 1 到 5 个传感器，这个数量不是随口定的。一路气体一个通道，常见配置是「目标气体 + 温湿度补偿 + 一氧化碳/硫化氢等交叉参考」，五路基本能覆盖一个典型监测点位的需求；再往上加，采样电路的功耗和标定维护成本会迅速上升，现场人员也记不住。GPS 负责给出位置，但罐区里金属结构密集，冷启动搜星慢、漂移大，所以节点安装时会同时把固定坐标写进配置，搜不到星就用固定坐标兜底，这一点后面在排查章节还会提到。

时间戳的精度也有讲究。终端自己的时钟会漂，一天漂几秒很正常，一年下来就是十几分钟，事后追溯时对不上中心侧的事件记录。通常的做法是节点每次与中继站通信成功时做一次粗略对时，把偏差压到秒级，超出容忍范围就在帧里带一个「时间不可信」标志，让中心侧知道这条数据的时间只能当参考。

2.3 三个硬约束：不能挖沟、不能保证视距、不能等

化工园区的现场条件决定了技术选型的边界，归纳起来是三条。

第一，不能挖沟也不方便引电。罐区、管廊、装置区都有防爆和动土审批，有线方案的前期成本不在设备，在施工。这条直接排除了大部分有线总线方案，也让中继站必须自带电源。

第二，视距不可假设。园区里到处是储罐、管架、钢结构厂房，两个点之间直线距离 800 米，中间隔两个罐子就可能完全收不到信号。这就要求网络具备绕行能力，而不是点对点硬扛。

第三，不能等。从探头检测到泄漏到形成可处置的告警，业务上要求在一分钟内走完。这条约束排除的是「先存本地、人工巡检时再导出」那类方案，也决定了数据链路必须是常连的，而不是按需拨号的。

把这三条摆在一起，剩下的技术路线其实不多。Ad-hoc 自组网的特点是节点之间可直连、无需固定网络平台、拓扑变化时自动组网和重建路由，正好对上「不能挖沟」和「视距不可保证」这两条，这也是原方案选择 JRc1 这类工业无线数传模块的原因。

2.4 需求到技术指标的转化

需求写在纸上都很好听，能不能验收，取决于有没有被翻译成可测量的指标。下表是这类项目里我通常会用的一份转化清单，左边是业务语言，右边是可以直接写进验收文档的数字。

3. 总体架构设计：终端、中继、中心三层与四类节点的职责划分

3.1 终端层：传感器、定位、电池三件套的配置逻辑

终端节点的硬件构成相对固定：1 到 5 路气体传感器、一块 JRc1 无线模块、一个 GPS 模组、一组电池。模块负责把传感器数据整理成帧、通过 Ad-hoc 网络发出去；电池决定了节点能挂多久不用人管。

这里的配置逻辑值得多说两句。传感器路数是一个可调项，不是越多越好。每多一路，就多一份采样电流、多一份标定工作量、多一份交叉干扰的可能。实践里的做法是先按「必测 + 补偿」两类来分：必测的是园区里实际储存、实际可能泄漏的那一两种气体；补偿的是温湿度这类环境量，用来修正主传感器的读数漂移。五路的配额基本就是这样用满的，而不是把所有能想到的气体全塞进去。

电池的选型不能只看标称容量。无线模块发射瞬间的峰值电流往往是平均电流的几十倍，如果电池的内阻偏大，发射那一刻电压被拉下去，模块直接复位，表现出来就是「数据时有时无」。通常的做法是按峰值电流选型，并在电源入口并联大容量电容做瞬态支撑，这一条比单纯堆容量有效得多。

3.2 中继层：太阳能供电与 3 到 5 公里覆盖的工程账

智能中基站的定位是「无线数据路由 + 中继站」，把 JRc1 无线传输模块和太阳能供电做成一体，不用数据电缆也不用电源线，覆盖半径 3 到 5 公里。这个数字在开阔地成立，在罐区密布的园区里要打折扣，工程上一般按 3 公里做规划、按 5 公里做理论校核。

太阳能这一块是典型的算账活，思路是先算日均耗电，再倒推板和电池。以一个典型中继站为例：模块收发平均功耗按 1.8 W 估，全天候运行一天就是 43.2 Wh。光伏板按当地有效峰值日照 3 小时、系统综合效率 0.7 折算，需要的板功率约为 43.2 ÷（3 × 0.7）≈ 20.6 W，实际选 30 W 留余量。蓄电池按连续阴雨 3 天续航：43.2 × 3 ≈ 130 Wh，用 12 V 系统就是约 11 Ah，取 12 Ah 的常见规格。这套算法不复杂，但一定要算，我见过直接把 10 W 板配 7 Ah 电池装上就走的，第一个雨季就集体掉线。

中继站的安装位置也有讲究。理想位置是园区的高点或者管廊顶层，天线尽可能抬高，避开罐体的菲涅尔区遮挡。两个中继站之间的间距要留重叠，让任何一个站故障时，边缘节点还有第二条路可走。这条在图上画起来简单，现场选点时经常因为「只有这个楼顶能上人」而妥协，妥协的代价后面会体现在链路稳定性上。

3.3 中心层：700 种物质数据库、扩散模型与情景再现

监控软件是整个系统的价值出口。它把实时数据和天气情况、地点信息、事故性质、危化源性质、泄漏量、地形等因素放在一起算，预测危化物的扩散范围，以及起火或爆炸对周边环境的影响。它内置一个包含 700 种以上化学物质的数据库，还有一个情景再现程序，能对天气和危化源做细节与总体两层分析，输出报告、图表、等值线和重要点位图。

从架构上看，这一层可以拆成四个部件：数据接入（收帧、校验、落库）、状态判定（阈值、变化率、趋势）、模型计算（扩散、影响范围）、呈现与输出（看板、报告、导出）。四者之间用消息队列或任务表解耦，模型计算是最慢的一环，让它异步跑，不阻塞告警通路。很多毕设版本在这里翻车，是把扩散模型直接写在收数据的回调里，一次计算几百毫秒到几秒，流量一上来整个接入线程就被拖死。

数据库那一块，700 种物质不是简单的一张大表。每种物质有分子量、沸点、蒸气压、毒性阈值、密度比空气轻重等属性，扩散模型要用到其中一部分，告警分级要用到另一部分。合理的做法是属性表与业务表分开，模型参数单独版本化，换一套参数可以复算历史情景，这对事后调查和责任认定很关键。

3.4 协议分层：Ad-hoc 自组网到底承担了什么

把通信这件事拆开看，Ad-hoc 网络解决的是下面三件事，而且都封装在模块内部的固件里，上层应用不用管。

一是自动组网。节点上电后扫描邻居、交换信标、选出到中心的最短路径，整个过程无需人工干预。二是自动寻路与重建。网络拓扑变化（节点掉电、遮挡变化、新增节点）时，各节点重新收敛路由，业务侧看到的只是短暂的时延抖动。三是覆盖延伸。节点之间可以直接通信，一个离中心很远的点位只要能找到中间某个节点，就能把数据接力送回去，等于用节点自己把覆盖范围撑大了。

对应用层来说，这套机制暴露出来的接口其实很窄：一个发送函数、一个接收回调、一份邻居与链路质量的状态。真正需要应用层操心的，是「发不出去的时候怎么办」——缓存、重传、补传，以及「怎么判断这条链路是真的断了还是临时抖了一下」。这两件事在后面第 4 章和第 5 章会具体展开。

4. 关键实现：数据帧设计、路由重建与告警判定

4.1 终端采集与组帧

终端节点的主循环不长，但要考虑的事情不少：采样、换算、定位、组帧、缓存、发送，每一步出错都会在中心侧表现为「数据不对」或者「数据没了」。下面这段是这类节点上我常用的骨架，跑在带串口和 ADC 的嵌入式 Python 环境里，逻辑可以直接照搬。

# 终端节点主循环：采样 -> 组帧 -> 入队 -> 发送 import struct, time SAMPLE_INTERVAL = 30 # 常规巡检采样周期（秒），应急模式可临时降到 5 MAX_QUEUE = 240 # 断网本地缓存上限，30 秒一帧约存 2 小时 RETRY_LIMIT = 3 # 单帧发送重试次数，超过即转缓存 def read_channels(channels): """channels: [(气体代码, 采集口, 标定系数k), ...]，数量 1-5""" out = [] for gas_code, port, k in channels: raw = port.read_adc() # 12 位 ADC 原始值 ppm = raw * k # 线性段换算；高浓度段另走查表，避免饱和后失真 out.append((gas_code, round(ppm, 2))) return out def battery_percent(mv): """按放电曲线插值，别用线性公式，锂电池中段太平会误判""" curve = [(4200, 100), (3900, 75), (3700, 50), (3500, 20), (3300, 5), (3200, 0)] for (v1, p1), (v2, p2) in zip(curve, curve[1:]): if mv >= v2: return int(p2 + (mv - v2) * (p1 - p2) / (v1 - v2)) return 0 def build_frame(node_id, readings, lat, lon, bat): """帧头 0xAA55 | 版本 | 节点ID | 时间戳 | 经度 | 纬度 | 通道数 | 通道数据 | 电量 | CRC16""" ts = int(time.time()) body = struct.pack('>HBIBiiB', 0xAA55, 1, node_id, ts, int(lon * 1e6), int(lat * 1e6), len(readings)) for gas_code, ppm in readings: body += struct.pack('>HH', gas_code, int(ppm * 100)) # 浓度放大 100 倍存整型，精度 0.01 ppm body += struct.pack('>BH', bat, crc16(body[2:])) # CRC 只覆盖业务字段 return body

代码里有三个参数值得单独说。SAMPLE_INTERVAL默认 30 秒，是常规巡检节奏；一旦中心侧对某个点位下发了应急指令，节点会切到 5 秒一帧，这时耗电会明显上升，所以应急模式必须带超时自动退出，否则一次演练就能把电池耗掉一截。MAX_QUEUE决定了断网时的数据兜底能力，240 帧按 30 秒算是 2 小时，超过就覆盖最旧的，这个取舍要在需求阶段和业务方确认。浓度放大 100 倍存整型是省字节的常规手法，代价是量程上限被限制在 655 ppm，超量程的气体需要单独走扩展帧。

电池百分比用分段插值而不是线性换算，是踩过坑之后改的。锂电池在 3.7 V 附近电压曲线很平，线性公式会把 60% 算成 40%，运维看到「电量不足」就跑去换电池，上去一测还有大半。

4.2 帧结构定稿

帧格式一旦定下来，后面所有环节都要围着它转，所以这张表要在动手写代码之前先定死，并且写进接口文档。

总长在 30 字节以内，对低速无线链路很友好。做过一次估算：100 个节点、30 秒一帧，每秒不到 4 帧，占用带宽可以忽略，真正吃带宽的是路由信标和重传。

4.3 自组网的入网与路由重建

模块固件承担了大部分路由工作，但应用层仍然需要一份自己的邻居表，用来判断链路是不是真的坏了，以及在必要时主动切换。下面这段是跑在节点侧的维护逻辑。

# 邻居表维护与父节点选择：跳数优先，跳数相同看链路质量 class RouteTable: LOST_LIMIT = 5 # 连续丢失信标次数上限，超过则拉黑 QUALITY_FLOOR = -88 # RSSI 下限（dBm），低于此值不参与选路 def __init__(self): self.neighbors = {} # {nid: {"hops": 2, "rssi": -71, "lost": 0}} def on_beacon(self, nid, hops, rssi): n = self.neighbors.setdefault(nid, {"hops": 99, "rssi": -120, "lost": 0}) n.update(hops=hops, rssi=rssi, lost=0) def on_miss(self, nid): n = self.neighbors.get(nid) if n: n["lost"] += 1 def pick_parent(self): cand = [(n["hops"], -n["rssi"], nid) for nid, n in self.neighbors.items() if n["rssi"] >= self.QUALITY_FLOOR and n["lost"] < self.LOST_LIMIT] return min(cand)[2] if cand else None # 无可用父节点时返回 None，转入缓存模式

这段逻辑的核心是那个排序键：先比跳数，再比 RSSI。只按 RSSI 选路会出问题——信号最强的邻居可能挂在一个拥堵的链路上，跳数多三跳，时延翻几倍。LOST_LIMIT和QUALITY_FLOOR是两个防抖参数：前者避免一次丢包就切路由引起震荡，后者避免节点挂到一个勉强能通、实际大量重传的邻居上。这两个值在现场要调，园区钢结构多的时候，RSSI 下限往往要比开阔地低 5 到 8 dB 才够用。

4.4 中心侧：从浓度到告警级别

收上来的浓度值本身不是告警，告警是「浓度 + 变化率 + 位置 + 持续时间」共同判定的结果。单点超阈值就报警，遇到传感器抖动会疯狂刷屏；只看持续超阈值，又可能漏掉突发泄漏。

# 告警判定：阈值 + 变化率 + 持续时间三条件组合 def classify(node, cur, hist, th): """ cur: 当前帧 {"ppm": 12.4, "ts": 1710000000} hist: 最近 N 帧列表，按时间升序 th: {"warn": 10, "alarm": 25, "rate": 5.0, "hold": 3} """ level = "normal" if cur["ppm"] >= th["alarm"]: level = "alarm" # 超上限直接升级，不等持续时间 elif cur["ppm"] >= th["warn"]: recent = [h["ppm"] for h in hist[-th["hold"]:]] if len(recent) == th["hold"] and min(recent) >= th["warn"]: level = "warn" # 连续 hold 帧都在预警线以上才报，抑制抖动 # 变化率：单位时间涨幅过大，即使没到阈值也提前提示 if len(hist) >= 2: dt = cur["ts"] - hist[-1]["ts"] if dt > 0 and (cur["ppm"] - hist[-1]["ppm"]) / dt * 60 >= th["rate"]: level = "alarm" if level == "normal" else level return level

判定之后才是模型计算：把点位坐标、泄漏物质、当时风向风速、地形数据喂给扩散模型，输出影响范围和等值线。这一层要异步跑，并且要有降级路径——模型算不出来的时候，至少要把「哪个点位、什么物质、多高浓度、什么风向」这四个信息推出去，应急人员凭这些也能做初判。

4.5 一次完整的链路验证

写完上面几段，别急着上现场。最省时间的做法是先做一次桌面链路验证：两个节点加一个中继，中间人为加遮挡（用金属板挡在中间），观察三件事——路由是否在 30 秒内收敛、断链后缓存是否补传、补传的数据时间戳是否还保持原始采集时间。这三条都过了，再谈现场安装。第 6 章的验收表其实就是这次验证的正式版。

5. 避坑与常见问题排查：五条现场才会暴露的细节

5.1 电池标称够用，实际一个月就掉线

现象是节点上线正常，运行两三周后陆续失联，取下来一测电池还有电压，装回去又能用几天。

原因通常有两个：一是发射瞬间的峰值电流把电压拉低，模块复位，复位后重新入网又要发一批信标，形成恶性循环；二是低温环境下电池内阻上升，标称容量打对折。这两种情况在实验室常温小电流测试里都看不出来。

解决方式是按峰值电流而不是平均电流选电池，电源入口并 1000 μF 以上的电容做瞬态支撑，低温场景改用低温型电芯，并且在固件里加一条「电压低于阈值就降低发射频次」的保命逻辑，宁可数据稀一点，也别让节点直接消失。

5.2 告警反复抖动，值班人员干脆不看

现象是同一个点位在预警线附近来回跳，一小时刷出几十条告警，值班人员很快就麻木了。

原因是判定只用了瞬时值，没有去抖和回差。传感器本身有噪声，浓度在阈值附近上下浮动是正常的。解决方式就是第 4.4 节那套组合条件：连续 N 帧超阈值才升级，恢复时用比触发线更低的阈值（回差），再加一个最短告警间隔，同一节点在窗口期内只推一条。

5.3 中继链路时通时断，画在图上覆盖没问题

现象是路测时信号满格，正式运行后某些点位的数据断续，重传率很高。

原因多半是天线高度不够，链路被罐体挡住了菲涅尔区。无线链路不是「看得见就能通」，路径中间要留出一块椭球形的净空区域，罐区里这块区域经常被占。另一个常见原因是中继站选点妥协在了低处。

解决方式是抬高天线、把中继站挪到视野更好的位置，实在没条件就降速率换灵敏度，或者在中间补一个节点做接力。判断方法很简单：看那条链路的 RSSI 和重传率，RSSI 尚可但重传率高，基本就是多径和遮挡的问题。

5.4 GPS 漂移或者干脆搜不到星

现象是同一个固定安装的点位，上报的坐标每次都不一样，偏差几十米；罐区内部的节点干脆一直无定位。

原因是金属结构遮挡和室内无星，冷启动时间不够。解决方式是安装时把固定坐标写进节点配置，作为主坐标；GPS 只用来做校验和授时，搜不到星或定位精度差于设定值时，直接使用固定坐标并置「定位来源=配置」标志。这样中心侧看到的点位永远是稳定的，不会在地图上乱跳。

5.5 传感器读数慢慢偏，标定周期没人管

现象是运行几个月后，同一个点位的基线浓度整体上移或下移，和隔壁点位对不上。

原因是电化学传感器的灵敏度会随时间衰减，温湿度变化也会带来漂移，园区里其他气体还存在交叉干扰。解决方式是三条：一是数据里必须带温度，中心侧做温度补偿；二是定期用标准气体做零点与量程标定，把周期写进运维计划而不是靠人记；三是配置一个参考节点，放在洁净背景点，用它的读数去修正其他节点的基线。这一条最容易被忽略，但它是「数据能不能用来做责任认定」的分水岭。

6. 验收与答辩：用一页表证明系统测得准、传得回、算得出

答辩现场最容易出现的场面，是讲了一堆架构图和协议细节，评委问一句「你怎么知道它准」，然后卡住。我的建议是把验收拆成可以当场演示的三段：测得准、传得回、算得出。每一段都准备一个可复现的验证动作，而不是一句「现场运行良好」。

演示顺序也有讲究。先演「传得回」——拔电源、加遮挡，让评委看到网络自己恢复；再演「测得准」——通标气，看曲线抬起来、告警按预期分级；最后演「算得出」——用刚才那次告警的情景直接跑一遍扩散模型，输出影响范围和等值线。三段时间控制在十分钟以内，比念二十页 PPT 有说服力得多。

还有一个细节：把失败路径也演一遍。故意让一个节点离线，展示中心侧多久发现、以什么形式提示、缓存的数据在恢复后怎么补上。评委问的很多问题，本质上是在探你有没有想过「坏了怎么办」，主动演出来，等于提前把问题答了。

血泪经验是第一次做这类系统时，我把所有精力放在模型和界面上，验收时被问「断网 30 分钟会丢多少数据」直接答不上来，因为压根没做缓存。从那以后我每次做监测类项目，都强制先把缓存和补传这条路径跑通，再动上层功能，顺序反过来大概率要返工。希望帮到你。

本文还有配套的精品资源，点击获取