供暖企业分级换热站运行数据采集与监管上报
供暖运行中，中控室需要掌握不同级别换热站的压力、温度、流量和阀门状态；政府部门的数据监管平台也需要按规定接收运行数据。如果现场数据分散在各站控制柜、仪表和不同系统里，值班人员既要核对运行情况，又要整理上报内容，同一批数据往往需要反复处理。
以一个采用分级换热的供暖企业为例：每座换热站都将上一级网络的热量交换到本级网络，再由本级网络承担相应的供热输送。本文按以下站级关系展开，使用过程为场景演绎，不代表已实施客户实绩。
| 换热站级别 | 上一级网络侧 | 本级网络侧 | 换热关系 |
|---|---|---|---|
| 一级换热站 | 一网 | 二网 | 一网向二网传递热量 |
| 二级换热站 | 二网 | 三网 | 二网向三网传递热量 |
| 三级换热站 | 三网 | 四网 | 三网向四网传递热量 |
这些是不同级别换热站各自对应的换热关系，不是一网、二网、三网都集中在同一座站内。每座站围绕上一级网络侧与本级网络侧分别采集数据，换热器两侧传递热量而不直接混水；站级、站点和网络归属需要同时标明。
按换热站采集两侧运行数据
接入时，先按“站级—站点—上一级网络侧／本级网络侧—设备—测点”整理数据，而不是把所有压力、温度变量混在一起。例如，“二级换热站 A—上一级网络侧（二网）—入水压力”与“二级换热站 A—本级网络侧（三网）—出水压力”是不同测点，不能只用“二网压力”“三网压力”代替站点与位置。
| 采集对象 | 每座换热站两侧分别建立的测点 | 使用时需分清的内容 |
|---|---|---|
| 压力 | 入水压力、出水压力 | 测点位置、单位、表压或绝压口径 |
| 温度 | 入水温度、出水温度 | 传感器位置及入水、出水的定义 |
| 流量 | 上一级网络侧与本级网络侧约定位置的流量 | 瞬时流量与累计量分别建点，不相互替代 |
| 阀门 | 开关状态、开度反馈、故障状态等已开放变量 | 实际反馈与控制设定值分开，按设备能力采集 |
| 其他运行指标 | 按现场需要扩展的循环泵状态、频率或设备故障等 | 以设备实际提供的数据为准 |
Woody 工业智能网关通过设备已开放的通信接口读取这些数据。例如，现场 PLC 已集中接入压力、温度和流量信号时，网关可按适配的 PLC 协议读取变量；仪表具备 Modbus RTU 或 Modbus TCP 接口时，则按仪表地址表配置采集。
只有模拟量输出、没有可通信接口的传感器，需要先接入匹配的 PLC 或采集模块，不能把网关的串口、网口当作模拟量输入端。对于不同站点或无法直接互通的设备网络，应按实际网络边界配置采集网关，不假定一台网关即可覆盖全部现场。
采集后，按项目约定统一字段名称、单位、量程换算和时间戳，并保留通信状态、数据有效性与最后更新时间。设备断线或数据超时，应在展示与上报逻辑中明确处理，不能把旧值当作当前值，也不能用零值冒充正常采样。
中控室看运行，监管平台收报文
这套方案的关键，不是“把数据联网”就结束，而是让采集数据分别进入两个明确的使用环节。
中控室按站级、站点和两侧网络集中展示
已有组态软件或供暖监控系统时，可按双方支持的协议或接口，将网关采集的数据接入现有系统，由该系统完成画面、趋势和业务展示，不必仅为新增采集重复建设一套界面。
没有合适界面时，也可利用网关本地 App 框架，按项目需求开发运行看板和趋势页面，在授权可达的中控室终端浏览器中查看。具体页面、历史记录和异常提示需配置或开发，并非接上设备就自动具备完整的供暖调度系统；历史数据保留范围也需结合存储资源规划。
以一级换热站单台机组的本地 App 组态为例，可以把上一级网络侧（一网）与本级网络侧（二网）的供回水温度、压力、流量，以及调节阀开度、循环泵状态和补水系统测点放在对应设备附近，让值班人员沿管路查看数据。界面中的“一次侧／二次侧”表示本台换热机组的两侧，并不是全企业网络编号的固定别名：在二级站，它们分别对应二网／三网；在三级站，分别对应三网／四网。温差、压差等计算值应与仪表采集值区分，并同时显示数据有效性和最后更新时间。
图中数值、状态与时间均为演示数据，页面为需定制开发、绑定实际测点的只读设计示意，不是已接入现场的操作界面。该图仅展示一级换热站的一组一网／二网换热回路，不包含二级站的二网／三网回路或三级站的三网／四网回路；其他级别换热站需建立对应站点和机组页面，不能直接沿用此图的网络标签。阀门写入的条件与控制权限见下文。
例如，值班人员发现某二级换热站本级网络侧（三网）的出水温度变化，可以先在该站页面对照上一级网络侧（二网）的温度、压力、流量与阀门反馈，再检查本级网络侧的循环泵及供回水状态，并核对更新时间与通信状态，再决定是否联系现场检查。界面帮助集中呈现信息，不应仅凭某个变化自动判定故障原因。
政府监管平台按接入规范接收数据
网关的数据发布功能可使用 MQTT、HTTP/HTTPS 等方式对接平台，也可通过 Lua 编写字段转换与推送逻辑。但政府平台使用什么协议、要求什么报文，必须以该部门实际提供的接入规范为准，不能把“支持 MQTT、HTTP”写成“无需适配即可接入所有监管平台”。
对接时，把企业、换热站级别、站点、所属网络、换热侧和测点编码，与平台要求的字段对应起来，再按规定的单位、时间格式、上报周期及鉴权方式组织报文。同样属于二网的测点，也应区分它位于一级站的本级网络侧，还是二级站的上一级网络侧，不能跨站合并或互相替代。监管要求的实时值、周期统计值和累计量应分别处理，不把瞬时采样直接当作统计结果。
中控室画面刷新频率与监管上报周期可以不同，按各自用途配置。上报后还应按平台接口规则处理响应或回执，让运维人员区分“数据已采到”“请求已发送”和“平台已接收”，而不是只看网关有没有联网。
遇到上行网络中断，可结合网关的离线缓存与断点续传能力设计补报。缓存容量、保留时间、恢复后的发送节奏，以及平台是否允许历史补报、如何去重，均需提前确认；补报保留原始采集时间，不能把历史记录改成当前数据，也不承诺无限缓存或数据绝不丢失。
前述采集与上报架构图以 WD2EC 的 4G 接入为示意。互联网接入可选 WiFi、4G 或有线，由客户按现场条件选择，并匹配相应型号；监管平台若要求专网或专用接入通道，应按其要求建设，不能以普通互联网链路替代。
阀门既要看反馈，也要管住控制权限
采集阀门状态，与修改阀门开度，是两件不同的事。只需监测时，采集已开放的状态与开度反馈即可，不因具备通信连接就开放写入。
针对企业提出的阀门控制需求，中控室可通过经过适配的控制界面和网关写入通道调整阀门。操作必须以设备支持、访问授权、现场确认和安全联锁有效为前提：先核对目标站点、阀门及允许写入的设定值，再下发指令，并读取实际开度或状态反馈，不能将“指令已发送”当作“阀门已到位”。现场 PLC 或控制器继续负责本地控制和安全保护；网关不替代安全联锁，通信中断时的阀门行为也应由现场控制方案明确。
政府平台的数据上报接口在本方案中只承担监管数据接收，不因此获得阀门控制权限。中控室的阀门控制与监管上报分别配置权限和处理流程，实施前确认可写变量、控制方式与联锁条件，不能把上报链路自动变成控制链路。
接入前，把两份清单对齐
一份是现场测点清单：明确一级站一网／二网、二级站二网／三网、三级站三网／四网的对应关系，逐站确认两侧入水、出水的测点位置，以及 PLC 或仪表型号、协议、变量地址、读写权限、数据单位和有效性规则。
另一份是平台对接清单：明确中控室系统接口与展示需求，以及监管平台的编码规则、报文结构、上报周期、鉴权、网络通道、回执和补报要求。对外上报只包含获准的数据字段，凭据与访问权限按项目要求管理。
两份清单对应后，网关负责把现场数据采集、整理并按约定发送；中控室系统或定制本地 App 负责展示；政府平台负责监管接收及其自身业务处理。供暖企业由此可以围绕同一套测点来源开展运行查看与监管报送，减少重复抄录和反复整理，同时保留清晰的数据来源、处理规则和控制边界。