★ FEATURED ARTICLE 做水利、地灾、基坑监测的朋友应该都熟渗压计是安全监测里最常见的传感器之一。水库大坝要测浸润线尾矿库要盯渗流场深基坑要查承压水水头几乎凡是跟地下水打交道的工程安全场景都绕不开这支几十厘米长的“水下体温计”。前些年我们去现场还得拿手持读数仪一棵一棵测桩回来再往Excel里敲数暴雨天想加密监测也跑不过来等第二天看到水位突变可能坡面已经出险了。这两年越来越多项目上了云平台安全监测方案渗压计接上采集终端数据通过4G、以太网或LoRa上传OneNET、tlink这类物联网云平台负责接收、存储和展示后台自动画曲线、推预警手机端随时可见。这篇就把我从传感器选型到上云调试的完整套路拆出来给准备上这套系统的朋友做个参考。1. 先搞懂渗压计安全监测到底在测什么1.1 测的是“孔隙水压力”不是简单的水位渗压计的中文名字很多也叫孔隙水压力计、渗水压力计测的其实是土体或岩体孔隙里的水压力。注意它不是水位计测的不是“水面到底有多高”而是土壤颗粒之间的地下水所承担的压强。静水条件下两者可以通过换算相互印证但现场大多不是静水条件所以安全监测里直接看压力更靠谱。现在主力用的振弦式渗压计测量原理是这样的传感器的头部有一片不锈钢膜片水压力作用在膜片上膜片变形后拉动一根绷紧的钢弦钢弦张力变振动频率就跟着变。采集仪通过激振线圈给钢弦一个激励电压让它在固定频率附近起振然后测谐振频率。出厂时每支传感器都有一张校准表给出基准频率F0和标定系数K再配合公式P K × (F0² − Fi²) b其中Fi是当前实测频率b是截距一般厂家会在证书里给全。频率的平方差与压力基本呈线性温度变化再按热修正系数补一个修正量这就是振弦式传感器稳定可靠的核心原因。这段讲得干巴巴但底层逻辑很重要。为什么强调“不是水位计”因为我在现场见过很多初学的人拿一根测绳去对比渗压计数值发现对不上就开始怀疑传感器坏了。其实同一孔里如果上层有毛细滞后、降水入渗或者负孔压渗压计读数和测绳水位本来就能差出一截。1.2 大坝、尾矿库、边坡和基坑为什么都要盯这个数据把场景摊开来说渗压计的价值就很直白大坝和堤防坝体内部浸润线升高意味着更多水从上游往下游渗透可能引发管涌、流土甚至坝坡失稳。把渗压计沿观测断面分层埋进去就能画出浸润线轮廓。尾矿库这是渗流预警最刚需的地方。库内水位、干滩长度、浸润线埋深全是尾矿库安全生产的硬指标。渗压计埋在坝坡里连续数天测变化比人工巡视可靠得多。深基坑和地下工程基坑里最怕承压水顶破坑底、发生突涌。降水井是否有放水效果、地下连续墙接缝是否跑水用渗压计沿基坑布点监测就能提前发现。边坡和滑坡降雨是滑坡的主要诱因本质是雨水入渗抬高了孔隙水压力把边坡的抗剪强度拉低。在滑体范围埋几支渗压计记录雨里雨后的压力曲线基本就能判断边坡处于稳定还是加速变形阶段。尤其是对于大范围工程人工巡检频率低且耗时云平台方案优势在于“连续”和“回放”晚上你可以看曲线变化数据告诉你在什么时候、哪个测点水悄悄发生了变化。1.3 传感器选型振弦式还是压阻式别选错维度振弦式压阻式/MEMS长期稳定性好适合数年至数十年埋设一般存在漂移适合短期项目输出方式频率/周期需要激振电路电压/电流/数字采集简单响应速度相对慢秒级毫秒级可做高频采集线缆要求激励和信号线多芯线四线制或两线制线缆要求低单点成本较高较低典型场景大坝、尾矿库长期监测基坑、科研、临时观测我自己的选型习惯是长期固定监测的闭眼选振弦式临时探明阶段或大量布点、成本敏感的才用压阻式。量程上不要把量程选太满要按照最大水压力的1.2到1.5倍留裕量否则膜片长期处于高应力状态零点会漂这是很多项目后期读数不准的隐形原因。另外还要区分总压力盒和渗压计前者测的是土压力与孔隙水压力之和别拿它当渗压计使。渗压计是专门测水压力的安装方式、滤水结构都完全不同混用了数据基本没什么参考价值。2. 云平台安全监测系统的链路设计2.1 传感器、采集器、云平台三层架构安全监测系统的骨架很固定用大白话说就是传感层渗压计负责把水压力变成电信号/频率信号。采集传输层数据采集仪或DTU负责定时激振、读数、换算再打包成JSON或Modbus上报。云端应用层OneNET、tlink这类物联网云平台负责设备接入、数据存储、曲线展示、报警推送。这层结构不是我们为了刻板才这样分而是因为现场设备种类太多振弦、485、数字、模拟、4G、LoRa、以太网如果不靠采集器在这一层做“翻译”云端就没法统一处理。打个比方渗压计像体温计采集仪像护士云平台像监控病情的值班医生。体温计不会自己跟医生说话中间的护士负责记录、判断、报警。对采集器来说最核心的指标是多通道、激励方式、采样间隔与掉电保持。比如一台8通道的采集仪第1到第8通道接振弦渗压计每5分钟自动激振一次读回频率本地SD卡缓存同时按MQTT协议发到云平台。断网时数据先存在本地网络恢复后再补传这个机制比“实时上传”重要得多。2.2 数据采集端选型4G DTU、W5500以太网还是LoRa现场没网用4G DTU现场有闸房或营地用W5500以太网点位密集且分散用LoRa。4G DTU是野外项目的首选简单粗暴一个铁壳子插SIM卡按配置连接MQTT broker内部带振弦采集驱动几分钟就能把设备接上云。缺点是偏远山区信号弱、物联网卡有有效期和流量费用后期要留意续费问题。W5500接入OneNET云平台是这几年以太网接入常见的一种做法。W5500是一颗集成了TCP/IP协议栈的以太网控制器通过SPI接口跟单片机连接。用它最大的好处是单片机不用自己维护TCP状态机W5500内部硬件就把封包、ARP、重传做掉了所以程序写起来简单稳定性很直接。现场只要布一根网线就省了4G卡的月租数据直接走内网或公网单点成本极低。在闸房、泵站、大坝坝顶这种有稳定电源和网络的地方我一般优先W5500。LoRa则适合几十个测点散布在几公里范围内的场区每个测点功耗低用电池跑一两年通过网关汇聚后再上传云平台。代价是要多设一个网关和组网调试。选择时要注意LoRa解决“怎么把数据拿到场区中心”4G/W5500解决“怎么把数据发到云平台”它们是两回事别混在一起选。2.3 云平台选型OneNET、tlink与自建平台怎么取舍云平台这一步常见的路线有三条OneNET是中移物联网推出的物联网云平台对国内开发者友好文档全支持MQTT、HTTP、CoAP、LwM2M等协议设备接入后自带数据流和存储做渗压计监测直接建“产品—设备—数据流”三层后台有现成的曲线图和大屏组件。OneNET云平台MQTT协议这一块最常被引用因为绝大多数DTU和以太网采集板都支持MQTT。tlink是另一个面向设备接入的物联网云平台也提供MQTT和HTTP接口特点是对中小项目更轻快规则引擎、报警通知直接在线配置做快速原型很顺手。很多做现场数据采集的同行拿它当“数据中转站”不想自己建平台就先把遥测数据推到tlink再通过开放接口拉回到自己的监测系统。自建平台的好处是数据完全在自己手里灵活性高比如用EMQX做MQTT broker、InfluxDB存储时序数据、Grafana做可视化。缺点是运维费心从broker高可用、数据备份到安全加固都要有人盯。若非项目有明确的数据合规要求中小型监测项目完全可以先落在现成云平台上跑通了再说。现在物联网云平台也开始卷“智能云平台”“深度学习云平台”这类概念可以把历史数据喂给模型做趋势预测、异常识别。我的观点是大数据分析和深度学习预测有探索价值但落到云平台安全监测方案上先把阈值报警、速率报警和链路稳定性做好比任何花哨的功能都实在。数据都传不稳再厉害的算法也没用。2.4 为什么不约而同用MQTT协议前面好几个方案的共同点是都选了MQTT。MQTT本质上是一个基于发布/订阅的轻量级消息传输协议适合网络不稳定、设备功耗受限、同时并发设备多的物联网场景。渗压计监测为什么不适合频繁用HTTP轮询因为每个测点可能几十秒到几分钟才需要报一次数据如果设备每隔几秒就发起一次HTTP请求流量很快吃掉电池也扛不住。MQTT的“长连接”特点是建立一条TCP连接后就一直挂着平时占用流量极小断了还能自动重连重连时再补发缓存数据。具体到上报格式我个人习惯是统一加“测点编号、时间戳、频率、温度、压力”五个字段JSON长这样{ sn: PZ-01, time: 1735000000, freq: 2456.8, temp: 12.3, pressure: 18.7 }topic命名要含有测点信息比如/project/dam/pz-01云平台上按topic做数据分流再通过dashboard按测点画曲线。QoS级别我建议用1QoS0可能丢数据QoS2的握手开销太重不适合采集器这种低算力设备。keepalive设置成30秒比较稳妥既能及时发现断线又不至于太频繁地刷心跳。3. 从埋设到上云的现场实操步骤3.1 渗压计埋设泡水饱和、钻孔回填的细节到达现场后第一个步骤不是打钻而是拆开渗压计泡水。渗压计头部的透水石里如果没有排除空气水和压力不会立刻传导到膜片上测值会滞后。正确的做法是把传感器竖直浸没在清水桶里至少泡24小时让透水石和膜片之间的空气排干净水完全充满感压腔。这步叫“预饱和”几乎所有厂家说明书上都会写但现场最容易被忽略。埋设操作流程大致是钻孔孔径一般要大于传感器外径5厘米以上钻进到设计深度后把孔内泥浆清干净防止泥皮堵住透水石。底部回填孔底先放一层干净的粗砂垫层厚度约20厘米到30厘米把泡好的渗压计轻轻坐在这层砂上保证透水石与砂层紧密接触。粗砂填充在传感器周围回填中粗砂形成一个人工透水段让地下水可以顺畅到达传感器。封孔与止水透水段之上用膨润土球或水泥浆做隔水段隔断上层水沿孔壁向下的渗流通道。如果现场用膨润土球要分层填入、逐层捣实粒径选5到10毫米的干球遇水膨胀后自动密实。电缆保护引出电缆不要悬空沿孔壁开沟埋设或穿入PVC保护管转弯处留一定余量防止变形和生物啃咬。这四步里最难做的是封孔止水。埋得浅的孔无所谓但深层孔如果上层有地下水不做隔水段上层水会沿着钻孔灌下来读数会从“局部孔压”变成“混合水位”现场排查起来特别头疼。一个我自己的土办法埋完后往孔口倒一点比较深的水比如倒个10升然后看测值有没有在几十分钟内变化。如果有明显抬升说明封孔出了问题赶紧返工。3.2 数据采集仪、供电和防雷的现场布置采集仪一般放在测点附近的机箱里机箱要防水防潮内部放干燥剂接线端子涂绝缘硅胶。很多人觉得机箱IP65就万事大吉实际打开一看端子已经发绿了就是因为雨天开箱时水汽进去平时又没透气孔。供电方案野外测点基本是太阳能板加蓄电池。渗压计本身功耗很低采集器才是大头。假设采集器休眠功耗30毫瓦5分钟唤醒一次读取并上报平均功耗在0.5瓦左右那20瓦太阳能板加38Ah的12V电池撑连续阴雨天七到十天问题不大。具体还要看采集器厂家功耗和冬夏阳光条件按这个思路去算就行。防雷不能省。信号线从传感器过来在机箱入口处要加信号防雷器电源输入端加电源防雷器机箱做接地接地电阻尽量做到10欧以内。渗压计往往埋在河滩、边坡这种空旷位置雷雨季节最容易感应出过电压不打防雷器打雷时损坏的不只是采集仪还可能顺路烧掉云平台侧网关。布线原则渗压计信号线要远离电源线和动力线并行布设时至少相隔30厘米避免工频干扰叠加。这个距离在大坝坝坡这种地方很容易被忽略最后测值乱跳排查一整天根源就是信号线和大功率水泵电缆绑在了一根桥架上。3.3 W5500接入OneNET云平台的一种低成本做法如果闸房、坝顶有现成的网线和电源用W5500这种方案最合适。我用一个很常见的组合单片机做主控W5500模块通过SPI接口连接Ethernet2库驱动MQTT库用PubSubClient。整体硬件成本非常低走以太网没有任何物联网卡费用调试也方便。Arduino代码骨架大致如下#include SPI.h #include Ethernet2.h #include PubSubClient.h // 平台分配的产品ID、设备ID和鉴权Key以自己平台最新文档为准 const char* deviceId pz-01-dev; const char* productId 123456789; const char* authKey YOUR_API_KEY; byte mac[] {0xDE, 0xED, 0xBA, 0xFE, 0x03, 0x01}; IPAddress mqttServer(183, 230, 40, 139); // 以云平台文档提供的broker地址为准 const int mqttPort 6002; EthernetClient ethClient; PubSubClient mqtt(ethClient); void setup() { Serial.begin(115200); Ethernet.begin(mac); delay(2000); mqtt.setServer(mqttServer, mqttPort); mqtt.setKeepAlive(30); mqtt.connect(deviceId, productId, authKey); } void loop() { if (!mqtt.connected()) { if (mqtt.connect(deviceId, productId, authKey)) { mqtt.publish(data, {\online\:1}); } } mqtt.loop(); static unsigned long lastSend 0; if (millis() - lastSend 300000) { // 每5分钟上报一次 lastSend millis(); float freq readVWFrequency(); // 读取振弦频率 float pressure convertPressure(freq); // 按系数换算压力 char payload[128]; snprintf(payload, sizeof(payload), {\sn\:\PZ-01\,\freq\:%.2f,\pressure\:%.2f}, freq, pressure); mqtt.publish(data, payload); } }同样注意上面代码里的IP、端口和鉴权参数要以你选定的云平台最新文档为准不同平台的MQTT连接参数可能存在差异特别是OneNET新旧版产品的broker地址都有变化。代码的意义在于它把“W5500接入OneNET云平台”这条链路完整串了起来W5500负责网络协议栈MQTT库负责报文剩下的业务代码只剩“读频率—换算—上报”三段。在W5500布线时还要注意模块供电是3.3V很多小板子带稳压直接用5V灌会烧网口变压器和RJ45座尽量选带隔离的否则雷电浪涌很容易顺着网线打到主控板。实测下来W5500的TCP连接稳定性很好连续运行几个月不重启也很常见。3.4 频率转压力、压力转水位的换算附计算例子渗压计给的是频率云平台上需要的却是压力和水位所以换算这步必须放在采集器或云端。换算公式就用第1节提到的P K × (F0² − Fi²) b比如一支振弦式渗压计标定证书上K2.5×10⁻⁵ MPa/Hz²F02500Hz截距b0。某次实测频率Fi2100HzF0² 6,250,000Fi² 4,410,000差值 1,840,000P 2.5×10⁻⁵ × 1,840,000 46kPa46kPa是什么意思呢标准状态下1米水柱约9.8kPa所以46kPa相当于4.69米水柱。这意味着如果渗压计埋设高程是100.00米测点处的地下水位高程就是100.00 4.69 104.69米。监测日报里看到的“浸润线高程”就是这样一段段换算出来的。温度补偿别忽略。夏天日晒、冬季水温差异都会让钢弦频率因热胀冷缩产生偏移。正规的换算流程是pressure 原始换算值 温度修正系数 × (当前温度 − 标定温度)。一些采集器把温度一起上报云端再修正就是给后端留了一个做精细化修正的口子。我建测点的做法是温度字段总是保留哪怕暂时不用将来做漂移分析也有数据。4. 云端展示、预警与短信通知的实现4.1 云平台上的测点建模与可视化配置登录OneNET或tlink后第一步是在控制台创建“产品”产品下面建“设备”每个设备对应一支渗压计或一个测点设备下面再定义“数据流”或“数据点”。比如一个测点就三条数据流frequency、pressure、temperature。这样后台数据结构清爽画曲线时也方便。数据流命名建议用“测点编号_参数”例如PZ01_pressure不要用中文API对接和跨系统拷贝时可省很多转义麻烦。显示名称用中文没关系内部标识保持ASCII。可视化大屏上除了曲线我建议至少放三个组件实时数值表、历史曲线、最近24小时变化量柱状图。实时数值表让值班员知道“现在是多少”曲线看“怎么变到现在的”变化量柱状图则负责发现突增突降。很多平台自带模板但我还是把它拼成一个能展示“趋势”的页面而不是单纯铺一堆数字。4.2 报警规则怎么定才不误报、不漏报报警是云平台安全监测方案的灵魂。报警规则有两种基本维度超限报警和变化率报警。超限报警最简单压力或水位超过设计管控值比如浸润线高程不许超过128.00米一旦超过就报警。变化率报警更灵敏一小时内水头上升超过0.30米就该提醒因为滑坡、管涌往往是过程性的单点数值还在控制线以内时变化速率已经先暴露了问题。我常用规则表做成这样级别触发条件响应动作提示超过警戒值的70%或日变化超过0.10米平台弹窗值班人员加强巡查预警超过警戒值或1小时变化超过0.30米短信通知项目负责人、监理警报超过危险值且持续15分钟或1小时变化超过0.50米短信电话启动应急预案这里有个容易踩的坑单一测点瞬时超限就去炸群消息事实上雨量、排水、检修都可能造成短时扰动一周下来大家就会对报警麻木。我在实际规则上加了两个阻尼一是连续触发2个周期才算数二是同一测点10分钟内不重复报警。关键报警要多测点交叉印证比如临近两支渗压计同时上涨才升级为警报。规则引擎放在边缘端做主判断也行边缘端的好处是即使云平台断网本地也能驱动声光报警器。现在的智能云平台还能训练“深度学习”模型做趋势预测但工程界更看重可解释性。我建议先拿标准统计模型比如移动平均、日变化率跑上一两个月积累数据之后再上机器学习否则模型判断依据不透明出事故时你没法跟业主交代。4.3 用Java调用HTTP短信接口发预警的实现示例云平台报警后真正让现场人员行动的是短信。这里以类似“云MAS平台”的HTTP短信接口为例Java工程里可以用Java 11自带的java.net.http.HttpClient实现。一般的短信接口都要求拼接鉴权参数和时间戳防止接口被恶意调用具体字段按短信服务商文档来但套路基本一致。import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.security.MessageDigest; public class SmsNotifier { public static void main(String[] args) throws Exception { String appId yourAppId; String signKey yourSignKey; long ts System.currentTimeMillis() / 1000; String nonce abc123; String sign sha256(appId ts nonce signKey); String body String.format( {\appId\:\%s\,\ts\:%d,\nonce\:\%s\,\sign\:\%s\, \mobiles\:\138****0000\,\content\:\大坝浸润线测点PZ01水位超限\}, appId, ts, nonce, sign); HttpClient client HttpClient.newHttpClient(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://sms-api.example.com/v2/sendSms)) .header(Content-Type, application/json) .POST(HttpRequest.BodyPublishers.ofString(body)) .build(); HttpResponseString resp client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(resp.statusCode()); System.out.println(resp.body()); } private static String sha256(String input) throws Exception { MessageDigest md MessageDigest.getInstance(SHA-256); byte[] digest md.digest(input.getBytes(UTF-8)); StringBuilder sb new StringBuilder(); for (byte b : digest) { sb.append(String.format(%02x, b)); } return sb.toString(); } }实际开发时注意三点接口必须走HTTPS内容里涉及中文要确保UTF-8编码签名不要用简单的MD5现在大多要求HMAC或动态签名报警短信内容写“测点编号当前值控制值建议动作”别只写干巴巴的数字不然值班的人看到了也不知道该怎么办。另外短信平台一般有模板审核机制正式项目要在报警上线前先把模板提交审核否则关键时刻发不出去这个环节要留一周左右的时间。4.4 监测报表与值班记录补全业务闭环云平台不能只停留在“看曲线、发短信”还要能导出报表。监测单位定期要交日报、周报、月报里面内容包括每个测点的最大值、最小值、平均值、变化量、报警统计。数据全都存在云平台数据库里报表程序按时拉取接口再填充固定Excel模板就能自动生成报表大幅减少手工整理。我在项目里习惯再加一份值班记录每天由系统生成值班日志列出当天报警次数、处理人员、现场核查结果最后汇总成PDF给业主。安全监测涉及安全管理责任做到有记录、有闭环比单纯堆传感器数据更让业主放心。5. 现场排查与长期运行避坑笔记5.1 读数乱跳、漂移怎么查渗压计读数乱跳我排查的顺序是先看线缆。信号线与动力线分开没屏蔽层有没有可靠接地接线端子有没有氧化机箱是否潮湿再判断“跳”的方式。如果是所有测点同时乱跳大概率是采集仪供电或外部强干扰问题如果只有一支测点跳重点查这一支传感器的线缆和信号防雷器。然后是漂移。振弦渗压计长期漂移有几个常见原因透水石部分堵塞、传感器线圈老化、零点频偏。可以拿便携式读数仪现场测同一支传感器与采集仪读数对比如果两次读数一致传感器没问题如果不一样先看通道激励参数是不是配错了。处理上我更愿意在采集层做滤波连续读取3次去掉最大最小取平均再上报。偶尔的毛刺值宁可揉掉也不要让脏数据堆到云端。5.2 设备离线、数据断点的排查顺序设备掉线云平台显示灰色排查顺序按这个来看设备现场指示灯电源灯灭就是供电问题网口灯或4G模块灯异常就是传输问题。登录采集器本地调试口看能不能读到最新测量值。读不到问题在传感器到采集仪这一段。读得到但云端没有问题在数据上报链路。先看MQTT topic、payload格式是否被平台拒收再检查设备的鉴权参数是不是被重置过。看是不是所有设备同时断。如果是考虑SIM卡被停机、网络欠费、公网IP变更或云平台侧故障如果只有单台检查该设备的物理链路。我在项目中踩过最大的坑是物联网卡默认到了有效期会停机停机后不会自动恢复。现场工人换卡后采集器如果没做在线看门狗一直用旧连接逻辑也不会自动重连。所以采集器程序要写“启动即连掉线重连重连失败就重启通信模块”的策略而不是把连接建立在初始化阶段就万事大吉。5.3 埋完数值不对多半是这几个原因新埋的渗压计数值和学生理论对不上先别急着怀疑传感器坏了常见原因有预饱和不充分透水石里有气泡压力传递滞后透水石被泥浆糊住钻孔后泥浆没洗净透水段被泥封锁封孔失效上层水沿孔壁和电缆向下渗流混合了多层水位高程记录错误换算水位时基准高程搞错差出好几米零点漂移新传感器埋设前没有在无压状态下记录初始频率或者运输颠簸导致零点偏了。我去年在一个尾矿库项目遇到过“测出来水位比库内水位还高”的情况死活查不出原因。后来把传感器吊出来才发现透水石上包了一层黄泥清洗后重新预饱和再埋测值立刻正常。泥浆堵透水石这种问题在钻孔压水反清环节里必须舍得用水冲够时间。5.4 长期运行避坑清单长期运行的项目后期问题往往不在传感器而在配套的“边缘环节”。我按频率列出几个每月一次现场巡检看机箱湿度、接线端子锈蚀、太阳能板遮蔽、蓄电池电压每季度一次数据传输率统计设备在线率低于90%的要查明原因每年一次零漂复测把渗压计做无压对比重新记录零点平台数据每日自动备份平台账号至少两人管理避免能力单点依赖报警规则参数变更要有版本留痕谁改了、什么时候改的、为什么改写清楚。这些东西没有什么高大上但很多项目倒就倒在没人盯着。设备是耐用品人却会疲劳只有把巡检和备份固化到制度里云平台安全监测方案才真的“能长期站着”。最后说一个我自己的习惯。每次项目快验收时我都会找一根埋在土里的渗压计做一个简单验证往孔口倒10升清水然后盯住最近5分钟内的测值曲线。如果曲线在半小时内出现一个缓坡抬升说明这支传感器和传感器到云端的整条链路是通的如果纹丝不动那不管后台界面做得多漂亮我都劝你先把链路查明白再签字。这个办法成本几乎为零但基本能帮我避免掉后面好几个月的扯皮。
阅读完成 · 觉得有帮助？
