做水文设备接入这几年，SL 651-2014 一直是我手里的主要依据。也是时候了解一下新版推荐协议 SL/T 812.1—2021 总则—SL/T 812《水利监测数据传输规约》，一共 6 个部分，其中 SL 651 被它「总结提炼」进去的来源之一。这篇笔记是我通读第 1 部分《总则》原文后整理的，重点记清三件事：这套标准为什么要出、6 个部分各自管什么、以及它给水利监测数据传输定下了哪些框架性规则。
和之前那篇 SL 651-2014 精讲 配合看效果更好：651 讲的是「具体报文怎么写」，812.1 讲的是「这些报文在整个水利行业里怎么被统一组织起来」。
一、先搞清楚这套标准为什么要出
标准原文的「引言」把动机说得很直白，我直接引一下关键句：
「水利行业建设了各种类型的自动监测（监控）系统，现阶段只制定了水文、水资源数据传输规约，已不适应业务应用发展需要，亟须建立水利各类业务统一的监测数据传输规约。」
「本标准以现有成熟的数据传输规约为基础，经总结提炼，提出一套适合水利行业各类监测系统运用的数据传输规约框架，以统一各类水利监测数据传输规约的技术要素。」
翻译成工程语言就是：以前只有水文（SL 651）和水资源（SL 427、SZY206）两套规约，但水利行业还有大坝安全监测、水土保持、城乡供水、水闸泵站监控等一堆场景，各自为政、各行其是。于是水利部信息中心牵头，把已有规约里的通用技术要素抽出来，做成一个「总则」，再按专业拆成 6 个部分。
所以第 1 部分的定位是：它是给「其他部分」立规矩的标准，同时也是水利监测系统数据传输设计的通用依据。原文「范围」里写得很清楚——「本标准适用于《水利监测数据传输规约》其他各部分以及水利监测系统的数据传输设计」。
二、SL/T 812 由 6 个部分构成
这是我认为最需要先记住的一张表，各部分的边界原文写得很克制：
第 1 部分本身「共 7 章、8 个附录」，2021-10-26 发布、2022-01-26 实施，主编单位是水利部信息中心，参编单位包括淮委水文局（信息中心）、中国水科院、河海大学、水利部大坝安全管理中心。
三、它和 SL 651、SL 427、SZY206 是什么关系
这是同行最常问的问题，我用原文事实回答：
引言明确写了，第 1 部分是「通过对行业标准 SL 651—2014《水文监测数据通信规约》、SL 427—2008《水资源监测管理系统数据传输规约》、项目标准 SZY 206—2016《水资源监测数据传输规约》 等现行标准以及实际应用情况进行总结提炼，提出……通用技术要素」。
它没有直接宣判 SL 651 作废。在水利部 2021 年第 11 号公告的「替代标准号」一栏里，SL/T 812.1—2021 是空的（同批发布的 SL/T 478-2021、SL/T 701-2021 才注明了替代旧版）。
所以现实中的状态是：现有的 SL 651 设备与平台照旧跑；新建项目、尤其是超出水文水资源范围的专业监测系统，按 SL/T 812 系列来设计。第 2 部分（水文水资源监测（控））才是和 SL 651 关系最直接的那一部分。
这一点在工程上很重要：对接老站时对方报的还是 651 的报文，不要因为「有 812 了」就把既有实现推翻。
四、先把术语对齐
总则的第 3 章几乎是一份「水利监测系统名词表」，而且定义都很短，值得记住——对接时吵架，往往就吵在这些词的含义上。挑几个我印象最深的：
两个细节值得单独说：
「智能传感器」的定义里强调了「双向通信」。这呼应了 SL 651 第 5 章里用 Modbus 读写传感器寄存器的做法——只会单向输出的，在标准语境里不算智能传感器。
标准正文里直接写了 MQTT 的术语。这说明 MQTT 已经被正式纳入水利监测的数据链路选项，不再是「野路子」。做物联网接入的同学可以放心往这个方向走。
五、6 条「基本规定」，容易被忽略但很关键
第 4 章只有六条，我把原文逐条列出来，并在后面加上我的理解：
六、组网结构：端对端 vs 扁平化
第 5 章第一节把组网架构分成两类，这是全文最「架构」的一段，也是方案评审时最容易被追问的地方：
标准同时给出了遥测站逻辑结构与监控站逻辑结构两张图。它们的差别本质上是「有没有控制回路」：遥测站是「传感器 → RTU → 信道」，监控站则包含现地主控/从控设备，要承担遥控、遥调的输出动作。
七、工作模式：自报、查询/应答、兼容
第 5 章第二节规定，端对端组网下可选用自报式、查询/应答式或兼容式三种工作模式。这点和 SL 651 的思路完全一致，但总则里明确写了自报触发条件及优先级顺序：
告警自报 > 要素值变化自报 > 特定条件自报 > 定时自报
这个优先级非常实用：它意味着一个遥测站在同一时刻有多个上报理由时，必须先发告警，而不是被定时报挤占信道。做站端固件或者做「漏报分析」时，这条可以直接当判据用。
八、传输链路协议：四条链路各管一段
第 6 章按「两个环节、两种技术路线」切分，我把 6.1~6.5 的结构整理成一张图：
[智能传感器] --6.2 MODBUS-RTU / SDI-12--> [遥测终端机 RTU] --6.3 专用传输链路协议--> [中心站]
--6.4 基于物联网通用协议--> [中心站]
[现地主控/从控设备] --6.5 监控系统传输链路协议--> [中心站]
6.2 智能传感器与遥测终端机：链路层面向串行接口，智能传感器侧以 MODBUS-RTU 为主，兼容 SDI-12；
6.3 遥测站与中心站专用传输链路协议：走自有信道时的链路层约定，是 SL 651 那一套的延续；
6.4 遥测站与中心站基于物联网通用协议的传输链路协议：这是新增的一章，对应扁平化组网和 MQTT 这类协议；
6.5 监控系统传输链路协议：面向水闸泵站等遥控场景，规范性引用文件里的 DL/T 634.5101、DL/T 634.5104（IEC 60870-5-101/104 体系）就是在这一段起作用的。
对比 SL 651-2014 只覆盖「传感器 ↔ RTU」和「遥测站 ↔ 中心站专用链路」两条链路，812.1 把物联网通用协议和监控系统都纳入了统一框架，这是最大的结构性变化。
九、数据通信规约：三个通用技术要素
第 7 章把「数据通信规约」拆成三条并行的线，和上面的链路一一对应：
结合 4.2 的规定，我理解这一章要统一的技术要素就是三样：信息元素编码格式、报文正文结构、报文帧格式。也就是说，以后不管哪个专业部分，这三样都必须从总则给定的口径里选，不能各写各的。
需要说明的是：第 1 部分把这些要素的框架和选项定下来了，但落到某一类具体要素的标识符表、功能码取值，仍要看第 2~6 部分对应的专业部分。所以实际做水文接入时，SL 651 和第 2 部分都还是要翻的。
十、8 个附录都管什么
总则的附录信息量很大，而且有几份是「资料性」的参考实现，可以直接拿来当编码依据：
两个我最关心的点：
附录 B 是 MODBUS 的整套操作示例，从查状态、查数值量到单点/多点遥控遥调都给了。以前调 Modbus 传感器全靠厂商手册，现在有了行业里的统一提法，写需求文档可以直接引用。
附录 C 把 CRC16 分成「正向校验 / 反向校验」。这正是我在 SL 651 那篇里强调过的坑——同一个生成多项式，初值、位序、是否结果异或不同，算出来完全不同。标准把两种算法都列出来，就是为了避免各算各的。
十一、落到工程上，我会重点关注这几件事
先确认项目该按哪一部分走。纯水文/水资源 → 看第 2 部分并参考 SL 651；水库大坝、水闸泵站 → 第 3 部分；水土保持 → 第 4 部分。别默认「都用 651」。
把术语表拿去对齐需求文档。遥测站/监控站/中心站这三个词混用，是写详细设计时最容易含糊的地方；监控站涉及控制回路，安全等级和遥测站不是一个量级。
站点分类码优先查附录 A，没定义的再自定义，并在项目文档里留档——4.3 给了自定义的权力，但要对后续对接方负责。
视频一律走 GB/T 28181（4.4）。海康、大华私有 SDK 接入可以用，但对外接口别做成私有协议。
自报优先级按 告警 > 变化 > 特定条件 > 定时 来实现，并在验收时用这个顺序做验证用例。
链路选型上，物联网通用协议已经「转正」。新建项目如果设备数量多、拓扑扁平，MQTT 这类方案可以直接写进方案书，引用 6.4 和标准里的术语定义作为依据。
十二、小结
学完 SL/T 812.1 之后，我对水利行业通信规约的理解从「一堆报文格式」变成了「一个分层体系」：总则统一技术要素，专业部分填充细则，链路层与通信规约分层对应，物联网协议和电力远动规约各就各位。它没有推翻 SL 651，而是把 651、427、SZY206 这些既有成果收拢进一个更大的框架里。
如果你也在做水利监测接入，我的建议是：SL 651 用来干活，SL/T 812.1 用来定架构和写方案。
本文依据的资料：
SL/T 812.1—2021《水利监测数据传输规约 第 1 部分：总则》标准原文（含前言、引言、章节 1~5 及全部附录目录）
水利部 2021 年第 11 号公告（批准发布 8 项水利行业标准）
水利部信息中心「传输交换类」标准介绍页
第 2 部分《水文水资源监测（控）》与 SL 651-2014 的逐条对照，我打算单独整理一篇，把「新增了什么、沿用了什么、迁移要注意什么」列成表。有同在做这块的同行，欢迎留言交流。