园区智慧能源平台实战：从能耗集采到碳管理

1. 项目定位与整体设计思路

1.1 园区智慧能源平台到底解决什么问题

我前两年接手过一个园区级智慧能源平台项目，园区里入驻了二十多家制造企业，有做注塑的、做机加工的、做表面处理的，再加上一栋办公楼和配套的宿舍区。业主方最开始的需求很朴素：每个月底各家企业的电费数据要对账，能耗费要分摊，碳排放要报给上级集团，但每个月都要靠人工汇总Excel表格，耗时耗力而且还容易出错。

这个项目的核心其实可以拆成两条线：一条是"能耗集采"，另一条是"碳管理"。能耗集采解决的是把园区内分散的企业用能数据统一采集上来，形成统一的能源台账；碳管理则是在能耗数据的基础上，通过排放因子换算成碳排放量，再进一步生成核算报告、配额管理建议、减排方案等。两条线叠加在一起，就是一套从底层数据采集到上层业务应用的完整智慧能源平台。

项目的价值体现在三个层面。第一层是园区运营方，可以通过平台实时掌握整个园区的能耗走势、识别异常用能、优化变压器容量配置；第二层是入驻企业，可以查看自己的能耗明细、对比同行水平、获取节能诊断建议；第三层是区域碳排放管理，园区作为基层单元，需要向上级报送碳排放数据，这个环节过去手工统计误差很大，平台化之后可以做到一键生成、有据可查。

我在项目初期对业主方做了一个详细调研，发现他们的核心痛点有三个：数据不准（人工抄表存在延时和错漏）、口径不一（企业内部台账与园区计费口径对不上）、报告耗时（月底集中出报表往往会拖延两三天）。所以说，这个平台的本质不是做一个"展示大屏"，而是把能源数据从采集、清洗、存储、计算到展示的整条链路彻底盘活。

1.2 系统分层架构与核心技术选型

我做这个项目时走的是标准的分层架构，分四层：采集层、数据层、平台服务层、应用层。采集层负责对接园区各企业的电表、水表、气表以及企业内部能源管理系统；数据层负责海量时序数据的写入、存储和查询；平台服务层承载能耗分项计算、碳排放核算、报表服务等核心业务逻辑；应用层面向园区运营方、企业用户、区域监管三类角色，提供Web管理端和移动端。

技术选型方面，我踩过不少坑也总结出一些经验。采集层我们最终采用的是边缘网关加本地协议转换的方案，网关部署在配电房或者弱电间，通过Modbus RTU、DL/T645等协议直接读取电表数据，再通过MQTT上传到平台，具体会在后面的章节展开讲。数据层用的是时序数据库TDengine，用来存电表每15分钟一个点的采集数据，吞吐量和压缩比都表现不错。平台服务层选择Java Spring Boot，原因很简单——团队对Java最熟，而且园区这类项目中Java的生态和运维资料都最完善。应用层前端用了React，数据可视化用了ECharts，移动端那部分考虑到后续可能打包成小程序，选择了Taro一套代码多端发布。

这里有一个很重要的选型原则：不要为了技术而技术。业内有同行喜欢把整个平台拆成微服务，每个模块一个独立服务，结果一个十来人的项目团队光维护服务间调用就耗费大量精力。我的做法是初期做成模块化单体，把采集服务、计算服务、报表服务拆成独立模块但部署在一个应用内，等到确实出现性能瓶颈了再拆。这个项目上线后最大接入量也就几百个采集点，单体架构完全扛得住。

这个架构里还要重点考虑数据安全问题。能源数据虽然不像金融数据那么敏感，但涉及企业生产运营情况，原则上不能对外泄露。我们在数据层做了租户隔离设计，每一家企业的数据在存储层面就带上租户标签，查询接口强制校验租户权限，避免出现越权访问。这个点看似不起眼，但真出问题就是合规事故。

2. 核心细节解析：从设备接入到能耗集采

2.1 多协议设备接入的方案设计与实践

园区里的能源计量设备五花八门，我在项目里实际遇到的设备就有四五种品牌，通信协议也各不相同。电表大多支持Modbus RTU和DL/T645两种协议，水表和燃气表用的是脉冲输出或者Mo