简介面向毕业设计、课程设计与工程实训等场景的智慧水务物联网系统是一套基于智能水表含NB-IoT水表、智能消火栓、智能阀门及RTU/PLC数据采集终端构建的供水监测管理方案。资源共2000个文件以js、css、html前端代码为主辅以json/xml配置、py/sh辅助脚本与sql数据库文件压缩包约61.66MB结构清晰便于按模块查阅。项目源码与工程文件均经测试运行正常可轻松复现配套说明有助于理解系统架构设计报告亦可参考借鉴。已有88人学习适合需要完整可运行项目作为毕设/课设起点或在此基础上扩展功能的学习者。1. 智慧水务物联网系统的第一个决策点选 NB-IoT 还是其他通信方式做智慧水务项目第一步不是写代码而是替用户单位回答一个问题智能水表的数据到底用什么通道传回来。这个决策直接影响后续的平台架构、协议解析和数据量预估也是最容易被当成反正是 IoT用什么不是用而糊弄过去的地方。常见的水表数据回传方案有 LoRa、Wi-Fi、4G Cat.1 和 NB-IoT很多毕设和课设默认选了 NB-IoT理由是运营商覆盖好、模块便宜、资费低。但实际做下来会发现NB-IoT 虽然叫窄带物联网它的通信特点决定了你的服务端不能按 HTTP 轮询的思路设计而要用设备主动上报 服务端被动接收的模式。这篇文章从水表报文结构讲起把整个智慧水务系统的数据链路拆开给出设备接入模块的代码骨架、平台侧的数据解析方案、可视化大屏的实现思路以及项目收尾时最容易被忽略的信号与上报链路验证方法。无论你的目标是大作业、实训还是竞赛这套框架都能直接复用。2. 智能水表与 NB-IoT 的通信原理从上报帧到抄表平台2.1 NB-IoT 技术特性与智慧水务的匹配逻辑NB-IoTNarrow Band Internet of Things构建在蜂窝网络之上使用 licensed 频段由运营商维护基站这意味着水表安装在地下表井、楼道管道间等信号遮蔽场景时依然能通过重传机制把数据送到基站。它的三个核心指标和智能水表的需求几乎是逐一对应的。第一是覆盖增益。NB-IoT 比 LTE 有 20dB 的覆盖增强对应穿透能力提升约 100 倍典型场景就是水表装在铁制表井盖下面或者嵌在混凝土墙里的管道井中。第二是低功耗。水表使用电池供电工作年限要求 6 年以上NB-IoT 的 PSMPower Saving Mode和 eDRXExtended Discontinuous Reception机制让设备在空闲时几乎不耗电只有在设定的上报时刻才唤醒并建链。第三是高连接数。单个 NB-IoT 小区支持约 5 万个终端而一个中型自来水公司的分区计量区域差不多就是几千到一万只表远远不会触到容量天花板。为了更清楚地说明选型依据我整理了一张方案对比表这个对比结果也直接对应智慧水务项目中为什么偏选 NB-IoT的答辩问题。通信方式覆盖能力功耗水平典型资费服务端设计方式适用场景NB-IoT强可穿多层楼板低电池可用数年按年计费每表约 10-20 元/年设备上行主动推送服务端被动监听分散、量大、无人值守的计量场景LoRa中需自建网关低无流量费网关成本高网关汇聚后转发至平台园区、厂区等私有网络内Wi-Fi弱依赖市电与路由器高不适合电池设备无设备主动 HTTP 上报室内近距离小规模演示4G Cat.1强较高模块功耗明显按流量计费可按 HTTP/MQTT 设计带宽充裕需要传输图片或频繁通信的现场从这张表能看出NB-IoT 在海量终端 低功耗 无人维护的智能水表场景下几乎是唯一解。但注意NB-IoT 的数据速率理论下行约 100kbps、上行约 60kbps实际应用层吞吐更低这决定了水表上报的数据必须短小精悍一个报文通常控制在几十字节以内。2.2 智能水表的报文结构先看懂十六进制再谈解析市面上的 NB-IoT 智能水表大多使用厂家私有协议通过 UDP 或 CoAP 将数据包发往运营商 IoT 平台再由平台通过 HTTP 或 MQTT 推送到用户单位的应用服务器。还有一种方式是水表直接走 MQTT 连接用户自建的 Broker这种方式对实验室环境和毕设项目更友好。无论走哪条链路最终应用层拿到的都是厂家定义的数据帧格式。我以实际项目中常见的一种无磁水表上报帧为例说明解析思路。典型的一帧 28 字节数据如下68 1B 00 00 04 33 12 34 56 78 90 12 34 56 00 00 00 02 00 03 01 02 03 04 05 06 7F 16这段十六进制不用急着逐段记关键是理解它的结构布局帧头68、帧长1B 即 27 字节、表地址BCD 编码的 12 字节表号、累计用量4 字节、瞬时流量4 字节、状态字1 字节、校验位和帧尾。解析时要特别留意表地址和累计用量是 BCD 码还是 HEX很多毕业生在这里翻车因为把 BCD 码当成普通十六进制整数计算后水量直接变成了天文数字。2.3 数据上报的完整链路水表到平台之间经过什么NB-IoT 水表数据到用户单位智慧水务系统的过程从上到下分为四层理解清楚这条链路才能知道你写的代码负责哪一部分。感知层是水表本体内部集成 NB-IoT 通信模组按照设定的时间周期通常每 2 小时或每天固定时刻唤醒并发送累计用量。网络层由基站和运营商核心网组成IoT 平台在这里完成设备认证和数据接入用户单位通常通过华为云 IoT、中国移动 OneNET 或电信 AEP 平台订阅数据。平台层是你要写的核心负责接收来自运营商平台推送的报文或者直连 MQTT Broker 订阅设备 topic完成解析、校验、入库。应用层则把数据变成抄表记录、实时曲线、漏损预警和分区计量报表。实际项目中用户单位如果已经买了运营商 IoT 平台的 license数据推送路径是水表 → 基站 → 运营商 IoT 平台 → 用户服务器你收到的报文格式往往是运营商平台上配置好的 JSON里面已经包含设备 ID、上报时间和原始负载。如果你的项目是完全自建那就让水表直接上报 UDP 包到你的服务器。我在下面一章给出两种模式的实现代码先讲自建 UDP 接收因为它的原理更底层也更容易在竞赛答辩时讲清楚。3. 服务端接入层实现Netty 接收 NB-IoT 上报数据3.1 为什么不用普通 HTTP 接口接收设备数据很多第一次做物联网项目的同学习惯性地用 Spring Boot 写一个RestController然后让水表 POST JSON 数据。这在 Wi-Fi 水表的小规模演示里没问题但当设备数量达到几百上千只且每只表定时批量上报时HTTP 的短连接模型会引入大量 TCP 握手开销移动网络下设备端的功耗也会上升。NB-IoT 场景下行链路带宽窄频繁建立 TCP 连接会让基站侧信令负载失衡。所以现在用户单位的智慧水务系统普遍使用两种方式一是用 Netty 搭建长连接 UDP 服务端二是接入 MQTT Broker 做异步消息订阅。UDP 更适合运营商平台直连推送MQTT 更适合自建平台架构。我自己的做法是优先把 Netty UDP 接收模块写好因为它不依赖第三方消息中间件部署简单答辩时逻辑清晰。3.2 基于 Netty 的 UDP 报文接收服务端代码创建一个 Spring Boot 项目在 pom.xml 中引入 Netty 依赖。下面这段代码实现了 UDP 服务端的启动和报文原始字节的接收import io.netty.bootstrap.Bootstrap; import io.netty.channel.*; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.nio.NioDatagramChannel; import org.springframework.stereotype.Component; Component public class UdpServer { public void start(int port) throws InterruptedException { EventLoopGroup group new NioEventLoopGroup(); try { Bootstrap bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioDatagramChannel.class) .option(ChannelOption.SO_BROADCAST, false) .handler(new ChannelInitializerNioDatagramChannel() { Override protected void initChannel(NioDatagramChannel ch) { ch.pipeline().addLast(new WaterMeterHandler()); } }); Channel channel bootstrap.bind(port).sync().channel(); System.out.println(UDP Server started at port: port); channel.closeFuture().await(); } finally { group.shutdownGracefully(); } } }这段代码的核心是NioDatagramChannel它把每个到达的 UDP 数据包包装成DatagramPacket不需要像 TCP 那样处理粘包拆包。ChannelOption.SO_BROADCAST设为 false 是因为我们只需要接收单播数据不允许广播包干扰服务端。实际部署时端口建议用 5683CoAP 默认端口或 9999 这类自定义高位端口。3.3 水表报文解析 Handler 实现紧接着写数据包的处理类这部分是智慧水务系统里最见功力的代码。每一家的水表电表协议字段定义不同但解析框架完全一致import io.netty.channel.ChannelHandlerContext; import io.netty.channel.SimpleChannelInboundHandler; import io.netty.channel.socket.DatagramPacket; import io.netty.buffer.ByteBuf; import io.netty.util.CharsetUtil; public class WaterMeterHandler extends SimpleChannelInboundHandlerDatagramPacket { Override protected void channelRead0(ChannelHandlerContext ctx, DatagramPacket packet) { ByteBuf buf packet.content(); if (buf.readableBytes() 28) { System.out.println(短帧丢弃 length buf.readableBytes()); return; } byte[] data new byte[buf.readableBytes()]; buf.readBytes(data); int frameHead data[0] 0xFF; int frameLen data[1] 0xFF; if (frameHead ! 0x68 || frameLen ! data.length - 2) { System.out.println(帧头或帧长校验失败); return; } // 提取表地址从第3字节开始取12字节BCD格式 String meterNo bcdToString(data, 3, 12); // 提取累计用量从第15字节开始取4字节单位立方米 long totalUsage bytesToLong(data, 15, 4); // 提取瞬时流量从第19字节开始取4字节单位立方米/小时 long instantFlow bytesToLong(data, 19, 4); System.out.printf(表号%s 累计量%d 瞬时流量%d%n, meterNo, totalUsage, instantFlow); // 这里调用 Service 层完成入库与后续业务逻辑 // waterMeterService.saveReading(meterNo, totalUsage, instantFlow, new Date()); } private String bcdToString(byte[] data, int offset, int len) { StringBuilder sb new StringBuilder(); for (int i offset; i offset len; i) { int b data[i] 0xFF; sb.append((char) ((b 4) 0x30)).append((char) ((b 0x0F) 0x30)); } return sb.toString(); } private long bytesToLong(byte[] data, int offset, int len) { long value 0; for (int i 0; i len; i) { value (value 8) | (data[offset i] 0xFF); } return value; } }逻辑说明先校验帧头0x68和帧长度防止网络传输中的乱序包。表地址按 BCD 码逐字节转换每个字节的高四位和低四位分别对应一个十六进制字符。累计用量按大端序拼成 long 型。如果水量超过 4 字节最大值可能要考虑字节序反转这取决于厂家协议解析前务必用真实报文对一遍。提示data[0] 0xFF是必须写的因为 Java 的 byte 是有符号类型如果不做无符号转换0x9F 这样的字节会被当成负数导致(byte)0x9F 0x9F判断失败。3.4 处理运营商平台推送的 MQTT 数据如果你的水表选型是直连 OneNET 或华为 IoT 平台服务端不需要面对裸 UDP 帧而是订阅平台转发出来的 JSON 消息。这时 Spring Boot 集成 MQTT 客户端即可import org.eclipse.paho.client.mqttv3.*; import org.springframework.stereotype.Component; Component public class MqttConsumer { private MqttClient client; public void connect(String broker, String clientId, String topic) throws MqttException { client new MqttClient(broker, clientId); MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(false); options.setAutomaticReconnect(true); options.setConnectionTimeout(30); client.setCallback(new MqttCallback() { Override public void messageArrived(String topic, MqttMessage message) { String payload new String(message.getPayload()); // payload 为 {deviceId:...,timestamp:...,data:十六进制原报文字符串} } }); client.connect(options); client.subscribe(topic); } }setCleanSession(false)的关键作用是让 Broker 保存离线消息设备上报时你的应用正好重启也不丢数据。NB-IoT 设备经常处于休眠状态应用服务器重启期间的消息丢失问题就靠这个参数兜底。4. 数据存储与分析从累计用量到分区漏损评估4.1 用水数据的数据模型设计水表上报的原始数据落到数据库时不能简单存一张宽表。智慧水务系统至少要拆成三张表设备基础信息表表号、安装位置、行政区划、口径、状态、实时抄表记录表表号、抄表时间、累计用量、瞬时流量、上报方式、告警记录表表号、告警类型、告警时间、处理状态。这里我用 MySQL 给出抄表记录表的结构CREATE TABLE water_reading ( id BIGINT AUTO_INCREMENT PRIMARY KEY, meter_no VARCHAR(20) NOT NULL COMMENT 水表编号, read_time DATETIME NOT NULL COMMENT 抄表时间, total_usage DECIMAL(12,3) NOT NULL COMMENT 累计用量(立方米), instant_flow DECIMAL(10,3) DEFAULT 0 COMMENT 瞬时流量(立方米/小时), battery_voltage DECIMAL(5,2) DEFAULT NULL COMMENT 电池电压(V), signal_level INT DEFAULT NULL COMMENT 信号强度(0-31), report_source TINYINT DEFAULT 1 COMMENT 上报来源:1-周期上报,2-唤应答,3-异常上报, UNIQUE KEY uk_meter_time (meter_no, read_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT智能水表抄表记录表;字段里最关键的是UNIQUE KEY uk_meter_time。NB-IoT 网络有个特点设备端发出数据后如果在一定时间内没收到网络层 ACK会自动重传服务端可能收到重复帧这个唯一索引就是防止重复数据入库的保险。total_usage用DECIMAL(12,3)而不是FLOAT因为浮点类型在累计计量上会产生进位误差水司对账时差一立方米都是麻烦。对于高频上报的场景比如竞赛项目中要求做用水异常实时检测MySQL 单表写入会成为瓶颈。这时常见做法是引入 TDengine 这类时序数据库按表号和时间戳建标签写入性能远超关系型数据库。TDengine 里建表语句更简单CREATE STABLE water_meter ( ts TIMESTAMP, total_usage DOUBLE, instant_flow FLOAT, battery_voltage FLOAT ) TAGS (meter_no BINARY(20), location BINARY(64));STABLE是 TDengine 的超表概念每只水表作为一个子表查询时按 tags 过滤特别适合分区计量分析。在毕设规模下MySQL 也已经够用不必强行上时序库增加部署复杂度。4.2 用量计算的常见误区日用量不能直接相减很多人做智慧水务时直接用今天的累计读数减去昨天的累计读数作为今日用水量。这个做法在理想连续上报下没错但 NB-IoT 水表的特性决定了它并不保证每次都上报成功。如果昨天没上报今天早上补报了两条记录那么今天读到的值 - 昨天读到的值就会把两天的用水量算到同一天导致夜间出现不可能的高用水量。我一般会在采集层做重采样转存用一个存储过程或定时任务把抄表记录标准化为整点读数INSERT INTO hour_reading (meter_no, stat_hour, usage_total) SELECT t.meter_no, DATE_FORMAT(t.read_time, %Y-%m-%d %H:00:00) AS stat_hour, MAX(t.total_usage) FROM water_reading t WHERE t.read_time NOW() - INTERVAL 2 HOUR GROUP BY t.meter_no, DATE_FORMAT(t.read_time, %Y-%m-%d %H:00:00);这段 SQL 每小时执行一次对同一小时内上报的多条记录取最后一条生成准实时的小时用水序列再做日用量汇总就不会被重复上报干扰。4.3 可视化大屏ECharts 实时刷新曲线智慧水务系统的展示层通常是一个大屏页面领导要看的无非三件事今日总用水量、与昨日同比、重点区域用水排名。ECharts 在这里是绝对主力下面这段代码实现了一个 5 秒刷新一次的实时流量折线图!DOCTYPE html html head meta charsetutf-8 title区域实时用水曲线/title script srchttps://cdn.jsdelivr.net/npm/echarts5.4.3/dist/echarts.min.js/script /head body div idchart stylewidth:100%;height:400px;/div script var chart echarts.init(document.getElementById(chart)); var option { title: { text: 东区供水干管瞬时流量 }, tooltip: { trigger: axis }, xAxis: { type: time }, yAxis: { type: value, name: m³/h }, series: [{ name: 瞬时流量, type: line, showSymbol: false, data: [] }] }; chart.setOption(option); // 每5秒从后端拉取最近2小时数据 setInterval(function () { fetch(/api/flow/latest?areaeastminutes120) .then(function (resp) { return resp.json(); }) .then(function (items) { chart.setOption({ series: [{ data: items.map(function (it) { return [it.time, it.instant_flow]; })}] }); }); }, 5000); /script /body /html后端对应的接口/api/flow/latest返回[{ time: 2024-06-15 10:30:00, instant_flow: 23.5 }]的 JSON 数组即可。setInterval做轮询是简单方案实际项目中更推荐用 WebSocket 推送避免大量间隔请求打满后端连接。展示层的视觉不是重点重点是数据口径准确图上出现的每一个波动都要能在库中溯源到某只表的某条上报记录。5. 上线前必须做的信号测试与上报链路验证很多项目在演示时出现水表数据显示不出来的尴尬问题往往不在代码而在 NB-IoT 模组和基站之间的附着过程没有完成。你可以在硬件端使用串口工具连接 NB 模组发送 AT 指令确认网络状态这是物联网安装调试员竞赛里上升为独立模块的技能实际项目里的排障顺序也是一模一样。先用串口连接模组执行ATCSQ查询信号强度返回如CSQ: 23,0其中 23 表示 RSRP 在 -75dBm 左右属于良好信号。如果返回值小于 10说明水表安装位置信号偏弱需要调整天线方向或加装外置天线。再执行ATCEREG?确认注册状态返回CEREG: 0,1表示已注册到网络若返回0,0或0,2则需要检查 SIM 卡是否欠费或未开通 NB-IoT 业务。服务端验证上报链路的技巧是先用tcpdump或 Wireshark 抓服务器端口上的 UDP 包确认真实报文到达后再启动业务进程避免业务代码内部 bug 和网络故障混在一起排查tcpdump -i eth0 udp port 9999 -XX -s 0抓包输出的十六进制内容如果与设备厂商提供的样例报文一致说明链路贯通问题在解析代码。如果不一致优先检查厂商平台的协议转换插件是否配置正确很多 NB-IoT 水表的自定义协议需要平台侧用 JavaScript 脚本转成标准 JSON 后再推送脚本中一个字节的偏移量错误都会导致整个报文被丢弃。最后建议项目收尾阶段做一个持续 24 小时的稳定性测试统计丢包率和迟到率。NB-IoT 水表在上报高峰期会出现少量数据延迟半小时以上的情况这并不一定是失败只是网络侧的队列延迟。你的平台要考虑按设备序号对累计用量做连续性校验如果某只表当前上报值小于上次上报值直接触发倒走告警这既是数据质量校验也是防作弊场景中的真实需求。本文还有配套的精品资源点击获取