简介：《无线传感器网络应用案例分析》是一份面向物联网、环境监测与化工安全管理方向学习者的案例文档，围绕WSN结合RAE systems气体传感器在化工园区污染指标实时测控中的应用展开，回应园区安全生产监督、突发泄漏快速认定与应急响应的实际需求。压缩包仅含1个doc文件，约15KB，篇幅精炼，便于快速查阅与课堂案例引用。文档从背景概述、系统组成和综合分析三部分组织内容，说明监测终端、中继站与监控软件的协同方式，并涉及Ad-hoc网络自动组网、路由重建及JRc1无线调制解调器在非视距工业环境中的传输特点。监控软件部分还介绍危化扩散范围预测、起火爆炸影响分析，以及报告、图表、等值点等输出形式，可帮助读者理解系统架构、部署逻辑与应急决策价值。目前已有849人学习下载，适合作为WSN应用入门与方案梳理的参考材料。

1. 环境监测的瓶颈不在传感器，而在那根不存在的线

一套化工园区的无线传感器网络（WSN）系统，探头能测几十种气体、分辨率做到 ppm 级，但只要数据送不出去，这套系统在事故面前就等于没装。真正决定它能不能活下来的，往往是三个和传感器毫无关系的问题：节点靠什么供电、链路断了能不能自己接上、事故发生的头十分钟里数据到底有没有到达监控中心。

这个案例值得拆开看，原因在于它把 WSN 里最容易被忽略的一层暴露得很清楚：网络形态是由部署环境反推出来的，不是由传感器指标决定的。理解了这层推导，再回头看那些自组网、多跳中继、太阳能供电的设计，就不会觉得它们是堆料，而会看到每一步都在解一个具体的约束。

2. 部署约束反推网络形态：为什么化工园区必须走 Ad-hoc 多跳

先看环境。一个化工园区动辄几平方公里，罐区、管廊、装卸台、污水处理区散布其中，金属罐体、钢结构管廊和建筑物把空间切成大量非视距（NLOS）的碎片。监测点要覆盖的是「可能泄漏的地方」，而不是「方便布线的路侧」。

2.1 罐区里的三重失效：布线、断电、非视距

第一重是布线成本。有线方案要开挖、要走桥架、要穿管，单位长度成本随距离线性上涨，而监测点的数量又必须足够密才有意义，两条曲线一乘，总价会失控。更麻烦的是化工区域的施工管理：动火、开挖都要走审批，施工窗口被压得很窄，一套系统上线周期被拖成几个月是常事。

第二重是灾害相关性。事故发生时，最先被破坏的恰恰是有线链路和市电——线缆沿管廊敷设，管廊本身就是事故高发区。有线方案在这里是负相关的：越是需要它工作的时刻，它越可能已经不在了。太阳能供电加无线回传的方案之所以被选中，本质上是在切断「监测系统」和「园区基础设施」之间的耦合。

第三重是非视距。无线链路在视距条件下可以传很远，但一旦中间挡了一排储罐，路径损耗会陡增十几到几十分贝。工业环境里多径、遮挡、金属反射叠加在一起，链路质量随时间波动是常态，这不是靠调大发射功率能解决的。

2.2 Ad-hoc 的本质：节点既是终端也是路由器

星型网络的分工很清楚：终端只负责发，接入点负责收和转发。这种结构的问题在于，所有终端的可达性都绑定在接入点的覆盖上，接入点覆盖不到的地方就是盲区，要补盲只能加接入点，而接入点又需要回传链路和供电。

Ad-hoc 换了一套分工：每个节点都同时扮演终端和路由器。节点 A 发不出去的数据，可以交给邻居 B，B 再交给 C，最终落到网关。原文说的「自动延伸网络覆盖范围」「在非视距或苛刻的工业环境中解决传输问题」，指的就是这个机制——覆盖不是靠单跳功率堆出来的，是靠跳数拼出来的。

这里有个值得算清楚的账。自由空间下接收功率与距离的平方成反比，工业遮挡环境里衰减更快；而多一跳的代价是转发时延和一次额外的收发。把发射功率从 100 mW 提到 1 W（约 10 dB），在衰减指数 3 的环境里距离只提升约 2.15 倍，但功耗涨了 10 倍、电池寿命直接砍掉一个量级。改成两跳，覆盖同样的距离，每个节点仍然只需要小功率。这就是为什么在电池供电的节点上，多跳几乎是唯一经济的选择。

2.3 3～5 公里中继半径是怎么来的

原文给出的中继站覆盖半径是 3～5 公里，这个数字放在园区尺度上刚好意味着两三个中继站就能覆盖一个开发区。中继站被设计成「集无线传输模块和太阳能供电于一体」的独立设备，不需要数据电缆也不需要电源线，安装位置可以选在屋顶、塔架、灯杆这些制高点上——架高 20 米带来的视距改善，往往比把发射功率翻倍更有效。

这张表里最容易被低估的是最后一行。对于应急类系统，「能不能在一周内把监测点铺到新划定的警戒区」往往比「峰值带宽多少」重要得多。Ad-hoc 的价值不在于性能更强，而在于它的部署成本近似于零边际——多放一个节点，网络自己会把它接进去，不需要重新规划。

3. 监测终端：1～5 个传感器、GPS 与一份电池账本

终端是整个系统里唯一真正接触被测介质的部分。按原案例的描述，一个终端可以挂 1～5 个传感器，配一个无线模块、一个 GPS 和一组电池。这个配置看着简单，但每一个选择背后都有取舍。

3.1 数据通路：为什么是 Modem 做汇聚，而不是每个探头一个无线模块

传感器输出的是电信号或数字量，本身不具备组网能力。如果给每个探头都配一个无线模块，成本、体积、功耗都会按传感器数量翻倍，而且同一个位置上的 5 路数据会各自走各自的路径到达中心，时间基准不一致，后端做相关性分析时很难对齐。

把汇聚放在 Modem 里，一次打包 1～5 路数据，附带同一个时间戳和同一个位置，好处是数据在源头就保持了时空一致性——同一时刻、同一地点的五种气体浓度是一组完整的样本，这在后面做扩散模型反演时是硬性要求。代价是 Modem 成了单点，它挂了整个终端就哑了，所以这类设备的固件通常会做看门狗和自动重启。

数据通路是这样的：探头采样 → Modem 采集并打包（时间戳、GPS、通道号）→ 通过 Ad-hoc 网络发给中继站或直接到监控中心 → 中心入库并对齐到统一时基。注意中间那条「或者直接到监控中心」——这是 Ad-hoc 的一个附带好处，节点发现网关在一跳之内时会直接发，不强制过中继，省一跳的时延和功耗。

3.2 采样周期、阈值触发与本地聚合

周期上报和阈值触发是两种思路：前者保证数据连续，代价是功耗恒定；后者省电，但可能漏掉缓变过程。实际系统里常见的是两者叠加，再加一层本地缓冲兜底。

# 终端采集与上报决策（伪代码，参数取典型工业节点量级，非产品实测值） SAMPLE_INTERVAL = 300 # 采样周期，秒 REPORT_INTERVAL = 300 # 常态上报周期，秒 ALARM_RATIO = 1.5 # 相对基线的跳变倍数，超过即触发即时上报 HYST = 0.10 # 回差比例，防止阈值附近反复触发 def tick(now, sensors, baseline, last_report, buf): frame = {"ts": now, "pos": gps_fix(), "ch": []} alarm = False for s in sensors: v = s.read() # 原始浓度值 t = s.temperature() # 同步采温度，供后端做温漂补偿 frame["ch"].append({"id": s.id, "v": v, "t": t}) # 只在超出基线 1.5 倍时判为异常，避免正常波动刷屏 if v > baseline[s.id] * ALARM_RATIO: alarm = True if alarm or (now - last_report) >= REPORT_INTERVAL: ack = modem.send(frame) # 交给 Ad-hoc 网络，异步等确认 if ack: buf.clear_acked(now) # 确认送达的样本才从缓冲删除 return now buf.push(frame) # 发送失败，先留在本地 return last_report buf.push(frame) # 未到上报点，落本地环形缓冲 return last_report

这段逻辑里有三个关键点。第一，采样与上报解耦：采样频率可以远高于上报频率，数据先落本地，上报时按需取，这样既保留了细粒度过程又不放大通信开销。第二，只有收到 ACK 才删缓冲：这是断链续传的基础，否则一次持续几分钟的路由重建就会在曲线上留下一个洞。第三，随包带温度：气体传感器的输出对温度敏感，后端不做补偿的话，夏天午后整条曲线会整体上漂，看起来像「全园区浓度升高」。

ALARM_RATIO这个参数不要照抄。基线应该按点位、按季节滚动统计得出，固定值在换季时会频繁误报——这是血泪经验里最常见的一条。

3.3 电池能撑多久：一次占空比的手算

电池容量是有限的，所以终端设计的第一步不是选传感器，而是算能量预算。按常见的工业节点配置估一下：12 V / 7 Ah 电池约 84 Wh，待机电流 20 mA，采样时 60 mA 持续 10 秒，发射时 250 mA 持续 0.5 秒，采样与上报都是 5 分钟一次。

待机功耗是压倒性的：0.24 W × 24 h ≈ 5.8 Wh/天。发射部分每天 288 次、每次约 0.0004 Wh，合计约 0.12 Wh。采样部分每天 288 次、每次约 0.002 Wh，合计约 0.6 Wh。三项加起来约 6.5 Wh/天，84 Wh 的电池能撑约 13 天。

这个数字解释了两件事。一是为什么终端不能承担中继职责：多转发一个包就是一次额外的收发，转发量一大待机功耗的优势立刻消失。二是为什么待机电流是真正的杀手：把待机从 20 mA 压到 2 mA，待机日耗从 5.8 Wh 掉到 0.58 Wh，总日耗降到 1.3 Wh 左右，同样的电池能撑到 60 天以上。工程上为省这几毫安做的努力（关断传感器供电、Modem 深睡、用中断唤醒而不是轮询）远比优化发射功率划算。

4. 中继站与路由：Ad-hoc 网络怎么「自己找路、自己修路」

终端算完账，结论是：它只能发，不能转发。那么谁来把几平方公里的数据搬回中心？答案就是中继站和它背后那套运行在 Modem 固件里的路由算法。原文提到「所有算法被综合在 Modem 内部的固件中，无需人工干预」，这句话是整套系统能否落地的关键——现场没人会去配置路由表。

4.1 按需路由：RREQ 广播与 RREP 回传

工业无线自组网里常见的是按需路由（reactive routing），AODV 是其中被讨论最多的一类。它的核心思想是：不维护全网拓扑，只有真需要发数据时才去找路。

一次完整的找路过程大致是这样：节点 A 有数据要发给网关，但路由表里没有可用条目，于是广播一个路由请求（RREQ），包里带着目的地址、跳数上限和本节点维护的序列号；收到 RREQ 的邻居如果自己也没有到网关的路由，就把 A 记为「反向可达」，把跳数加一后继续广播，同时丢弃重复的 RREQ 防止风暴；网关收到后，沿反向路径单播一个路由应答（RREP）回去；沿途每个节点收到 RREP 时建立到网关的正向路由，最终 A 拿到一条完整路径，开始发数据。

路由表条目大致长这样：

# 路由表条目（字段取 AODV 类协议的典型结构） route = { "dst": "gw-01", # 目的节点标识 "next": "n-17", # 下一跳，只关心这一步交给谁 "hops": 3, # 到目的的跳数，越小越优先 "seq": 4127, # 目的序列号，越大表示信息越新 "expire": 1712, # 过期时刻，超时即视为不可用 "metric": 0.82, # 链路质量或 ETX 度量，用于多路径择优 } def pick(route_a, route_b): # 优先选序列号新的，其次跳数少的，最后看链路质量 if route_a["seq"] != route_b["seq"]: return route_a if route_a["seq"] > route_b["seq"] else route_b if route_a["hops"] != route_b["hops"]: return route_a if route_a["hops"] < route_b["hops"] else route_b return route_a if route_a["metric"] < route_b["metric"] else route_b

序列号这个字段容易被忽略，但它是防环的核心：目的序列号保证了节点不会拿一条「比自己已知信息还旧」的路由来用。如果没有它，网络分区后重新合并时很容易出现 A 指 B、B 指 A 的循环，包在里面转圈直到 TTL 耗尽——现象就是「节点明明在线，数据就是不上来」。

expire和metric是工程上更实用的两个字段。纯跳数路由在无线环境里会翻车：两跳的高质量链路往往比一跳的临界链路更稳，只按跳数选路会挑到那条随时会断的。用 ETX（期望传输次数）之类的度量能纠正这一点，代价是需要持续统计链路的收发成功率。

4.2 拓扑变了怎么办：链路失效检测与重建

自组网的「自」字体现在这里。拓扑变化在园区里是常态：一辆槽车停在节点和中继之间，链路质量就塌了；中继站的蓄电池进了低电压保护，整片区域的可达性瞬间改变。

检测通常靠三层信号叠加：链路层 ACK 连续丢失超过阈值、上层一段时间没收到邻居的周期性信标、以及收到邻居发来的路由错误（RERR）。三者中任意一个成立，节点就把对应路由标记为不可达，向上游发 RERR，源节点收到后重新发起 RREQ。

重建过程有两个参数决定体验。一是 RREQ 的重试间隔：退避太激进会在拓扑刚变化时引发广播风暴，退避太保守则表现为事故发生后十几秒数据不动。常见做法是指数退避加随机抖动，首试 1 秒以内，最多试三到五次。二是路由缓存时间：缓存太久会用到已经失效的路径，缓存太短则每次发数据都要重新找路。经验值是让缓存时间略大于典型的数据间隔。

原文强调「当网络拓扑发生变化时，各节点能自动组网、自动寻找路由、自动重建」，翻译成可验证的行为就是：拔掉任意一个中继，网络应在秒级到十几秒内恢复连通，且这个过程不需要人工介入、不需要重启设备。这条是可以现场验证的，也是验收时最该测的一项。

4.3 太阳能中继站的能量中立：从功耗倒推占空比

中继站不需要数据电缆和电源线，靠太阳能板加蓄电池独立运行。这意味着它的设计目标不是「性能最好」，而是「能量中立」——全年平均发电量必须大于平均耗电量，而且要在最差的季节也撑得住。

算法很朴素：先估平均功耗，再除以等效日照小时数，得到太阳能板的最小功率，然后加余量。假设中继站平均功耗 2 W（收发占空比约 5%，其余时间待机），当地最差月份等效日照按 4 小时算，板子至少要 12 W，再留 30% 余量取 16 W 左右。蓄电池则要按连续阴雨天数配，常见是按 3～5 天自持能力设计。

这里的取舍在于占空比。中继站如果把接收机常开，能第一时间接住邻居的包，时延最低，但功耗可能是待机模式的几十倍，太阳能板要跟着翻几倍。反过来，让中继站周期性地唤醒监听，能大幅降功耗，代价是端到端时延变成「唤醒周期」的量级。对于分钟级上报的环境监测，这个代价完全可以接受——这也是为什么这类系统的实时性通常定义在秒级而不是毫秒级。用错了场景就会出事：如果拿这套参数去做泄漏瞬间的联锁切断，那一定会翻车。

5. 常见问题与排查：组网、功耗、数据链路上的五个坑

现场问题有个共同特征：现象和根因隔得很远。下面这几条都是这类系统里反复出现的。

5.1 组网类：节点「在线」但数据不上来

现象：监控界面上节点状态是绿的，链路质量也显示正常，但曲线是平的，或者隔很久才来一个包。

原因：第一种可能是陈旧路由。路由条目靠expire过期，但如果设备时钟不准或者序列号处理有 bug，一条已经断掉的路径会一直「看起来有效」，数据发出去就石沉大海。第二种可能是单向链路：节点的发射功率够、对端的接收灵敏度不够，或者反过来，导致「能听见对方」但「对方听不见自己」，握手阶段的统计看着正常，实际数据方向是断的。

解决：排查时不要只看「是否收到过包」，要看双向握手成功率，把收发方向分开统计；路由表打印出来对照expire和seq，确认没有长期不更新的条目；现场测试时把节点从远端往近端逐个挪，观察在哪一档开始恢复，能快速区分是覆盖问题还是路由问题。

5.2 供电类：中继站到了后半夜就掉线

现象：白天数据完整，凌晨两三点开始丢包，天亮后自动恢复，日复一日。

原因：能量预算没按最差工况做。太阳能板积灰、冬天日照角低、蓄电池低温容量下降，三个因素叠加，白天充的电撑不到天亮。另一种常见原因是中继站自己不上报状态——它被当成「基础设施」而不是「被监测对象」，所以电池电压低到保护点之前，中心侧完全看不到征兆。

解决：能量预算按最差月份算，不要用年均值；把中继站的电池电压、充电电流、太阳能板输出当成一路遥测上报，让它也进监控界面；在低电压保护之前设两级告警，留出人工干预的时间窗口。这条算是最典型的「后悔药」——等出事那天才发现中继站从来没上报过自己的状态。

5.3 数据类：浓度跳变、GPS 漂移与时间戳错位

现象一：浓度曲线在中午出现周期性尖峰，早晚正常。

原因：探头温漂，加上机箱被太阳直射，箱内温度比环境高十几度。传感器输出随温度上漂，如果后端不做补偿，看起来就像园区在中午集中排放。

解决：每个通道随包上报温度，后端按标定曲线做补偿；机箱加遮阳和通风；基线按季节滚动更新，而不是全年固定。

现象二：两个相邻点位的读数对不上，事后复盘发现是数据「错位」了。

原因：GPS 在罐区多径严重，定位漂移几十米；更麻烦的是时间——如果中心用「到达时间」而不是「采样时间」入库，路由重建期间积压的数据会在恢复后集中到达，全部被记成同一时刻，曲线出现一个虚假的尖峰。

解决：固定点位首次定位后把坐标固化到配置里，GPS 只做校验和防拆检测；所有数据以采样时间戳为准，到达时间只用于统计链路时延；终端做时间同步（GPS 秒脉冲或网络对时），保证多节点数据可对齐。

现象三：事故后调数据，发现关键几分钟是空的。

原因：本地缓冲被循环覆盖，或者断链期间数据直接丢弃，或者缓冲区没做掉电保护，断电后全丢。

解决：缓冲容量按「最长预期断链时间 × 采样频率」估算，宁可多留；写入用追加而不是覆盖，或至少在覆盖前把最老的数据标记为已归档；缓冲区加掉电保护。这个黑匣子属性平时看不出价值，出事那天就是唯一证据。

6. 监控软件：从一串浓度数字到一片扩散范围

数据到了中心，问题才刚变成业务问题。管委会要的不是「3 号点测到 20 ppm」，而是「泄漏源在哪、影响范围多大、要不要疏散、往哪个方向疏散」。这一步由监控软件完成。

6.1 模型吃进去的是什么

按原案例的描述，软件把数学计算法则与天气情况、地点信息、事故性质、危化源性质、扩散或泄漏情况、地形学结合起来，预测危化物的扩散范围以及起火爆炸对周边环境的影响，底层是一个含 700 种以上化学物质的数据库和一个情景再现程序，输出报告、图表、浓度等值线和事故总体影响分析。

连续泄漏通常用烟羽模型（高斯烟羽一族）算稳态浓度分布，瞬时泄漏用烟团模型算随时间的推移；密度大于空气的气体还要考虑重气效应，下沉后沿地面铺开，这时高斯模型的假设已经不成立，需要重气扩散模型。这里最常见的误用是拿一个模型套所有场景：同样是泄漏，液池蒸发和高压喷射的源项完全不同，算出来的范围能差一个量级。

情景再现的价值在于校准。把历史某次事件的监测数据回放进模型，比对模拟结果和实测曲线，如果系统性偏大或偏小，就说明源项假设或稳定度分级有问题。没有这一步，模型输出的等值线只是一张好看的图，没人敢拿它做疏散决策。

6.2 边缘还是中心：一个绕不开的取舍

这套系统里最值得琢磨的取舍是：哪些计算放在节点上，哪些放在中心。

直觉上应该尽量往边缘放，减少通信量。但在这类场景里恰恰相反。终端是电池供电的，算力有限，模型需要持续更新，把扩散计算放到边缘意味着每个节点都要维护一份物质库和气象数据，功耗和运维成本都会失控。真正合理的分工是：边缘只做判决，中心才做预测。节点负责判断「当前值是否异常、变化率是否异常」，这只需要阈值和滑动窗口；中心拿到原始浓度、位置、时间，才做源强反推和扩散计算。

这个分工也解释了为什么终端上报的是原始数据和位置，而不是一个「正常/异常」的结论——结论会随模型更新而变，原始数据不会。把不可逆的判断留在边缘，等于把模型迭代的可能性提前扔掉了。

从那以后我每次评估这类方案，都会先问一句：断网三十分钟，数据还在不在？如果答案是「不在」，那前面所有的传感器指标和模型精度都可以先放一放。希望帮到你。

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