简介这是一套面向能源管理场景的EMS能源管理系统完整源码包底层基于物联网技术覆盖企业、工商业、低碳园区、化工、工矿及公共建筑等多维度的能碳管理需求能够对水、电、气、热等能耗数据进行采集、监控与统一管理。代码经过严格调试下载即可运行适合计算机相关专业学生作为课程设计、期末大作业或毕业设计的参考项目也适合具备Java基础的技术学习者深入研究工程实现。资源包含1386个文件、压缩包约19.5MB其中741个Java文件构成后端业务逻辑199个Vue文件承载前端页面另有SQL脚本、静态资源与部署环境配置阅读者可以获得从数据采集到前端展示的完整闭环。目前已有138人学习浏览整体是一份兼具业务广度与代码完整度的能源平台实战资料。1. 能源管理系统到底在管什么先想清楚 EMS 的边界再决定买还是自研配电房里几十块多功能电表数据都在本地月底靠 Excel 抄表对账——这是大多数企业上能源管理系统EMS之前的真实状态。EMS 能源管理系统做的事是把分散在各配电间、车间和楼宇的电表、水表、气表数据汇到一个平台上完成分项计量、成本核算、异常告警与负荷优化。它解决的从来不是“没有数据”而是“数据躺在表计里没人用”这个老问题。这篇文章写给工厂、园区、商业楼宇和储能电站的从业者也写给打算拿源码做二次开发的集成商。我会按自己做过项目的顺序把链路拆开先讲数据怎么采、怎么存再讲源码怎么选、平台怎么部署最后落到分项计量和告警这些核心功能以及一份可以直接照做的避坑清单。2. 拆开 EMS 的数据链路从电表脉冲到平台看板中间要过几道关我接手过好几个“平台买了但没人用”的项目查到最后几乎都是同一个根因数据链路没打通。所以先别急着选平台、比价格先把一条数据从电表走到看板的每一关摸清楚。这一章讲三层架构、Modbus 采集配置和时序数据库选型这三件事决定了整个能源管理系统EMS的地基稳不稳。2.1 三层架构采集层、平台层、应用层各管什么事EMS 的主流架构是三层常见做法是把采集、存储计算、业务展示彻底分开。第一层是采集层包括多功能电表、水表、气表、温度传感器这些计量设备以及边缘网关、串口服务器这类通信设备。现场设备负责出数据网关负责把数据从 Modbus RTU、DL/T645、BACnet、IEC 104 这些协议里解析出来再往上送。这一层的核心不是设备本身而是协议解析的完整性。很多项目翻车都翻在协议上比如电表厂家对 645 协议实现不标准或者寄存器地址和手册对不上读出来的数据明显离谱。第二层是平台层通常由一个采集服务、一套消息队列常见做法是 EMQ X 或 Mosquitto、一个时序数据库、一个规则引擎组成。采集服务只干一件事按轮询周期把设备数据读上来转成统一的数据模型。消息队列负责削峰避免设备多了以后采集波动直接打崩数据库。时序数据库存分钟级甚至秒级的历史数据。规则引擎做告警判断和联动逻辑。第三层是应用层就是用户能看到的看板、报表、告警、电能质量分析、能耗对标这些功能。这一层离业务最近也是选型时最容易看花眼的地方。我的建议是先看前两层能不能撑住再看应用层有什么功能。因为应用层功能后期都能加但采集链路如果基础没打好换个平台也救不回来。为什么一定要分层因为这三层的生命周期不一样。采集层跟着现场设备走设备换了协议就换平台层跟着数据量走数据量大了可以横向扩容应用层跟着需求走老板要什么报表就加什么报表。混在一套代码里后期每次改动都要动整个系统返工成本很高。2.2 Modbus 采集配置先从一块电表把数据读上来在能源管理系统里Modbus RTU 是绝对的主流协议原因是绝大多数多功能电表都支持它而且实现简单一条 RS485 总线上可以挂 32 台甚至更多设备。下面这段代码是用 Python 的 minimalmodbus 库读一块电表的电压、有功功率和电度这是整个采集链路里最小可用的单元。import minimalmodbus # 串口 /dev/ttyS0从站地址 1 meter minimalmodbus.Instrument(/dev/ttyS0, 1) meter.serial.baudrate 9600 meter.serial.bytesize 8 meter.serial.parity N meter.serial.stopbits 1 meter.mode minimalmodbus.MODE_RTU meter.close_port_after_each_call True # 读电压寄存器 0x00003 位小数 voltage meter.read_register(0x0000, 3, functioncode3) # 读有功功率寄存器 0x00043 位小数 power meter.read_register(0x0004, 3, functioncode3) # 读正向有功电度寄存器 0x00062 位小数 energy meter.read_register(0x0006, 2, functioncode3) print(f电压 {voltage} V功率 {power} kW电度 {energy} kWh)参数里面波特率、数据位、校验位、停止位必须和电表侧完全一致常见配置是 9600、8、N、1但我在现场遇到过好几块表是 4800 甚至 19200 的。寄存器地址不是随便写的0x0000、0x0004、0x0006 需要对照电表厂家提供的寄存器映射表不同厂家差异很大。functioncode3 表示读保持寄存器一般电度、电压、电流都在保持寄存器里少数电表的电度放在输入寄存器里就要用 functioncode4 去读。这里最容易被忽略的是 close_port_after_each_call True。RS485 半双工总线上如果你不释放串口下一个设备的读取请求会卡住导致整个总线的轮询超时。我最早做采集程序的时候没注意这个参数挂 5 块表就频繁丢数据排了一整天才发现是串口占用问题。另一个常见坑是串口设备被两个进程同时打开读取和写入互相干扰数据出现乱码这种问题用 lsof 查一下进程对串口的占用就能定位。2.3 时序数据库选型分钟级数据为什么要换存储很多初次做能源管理系统的人会想数据量不大用电表数据存 MySQL 不就行了先算一笔账1000 个测点15 分钟一条一天是 96 条一年下来是 1000 × 96 × 365 3504 万行。如果做到 1 分钟粒度一年超过 5 亿行。这个量级在 MySQL 单表里做聚合查询索引再优化也会越来越吃力更别说还要跑同环比、分项汇总这类高频查询。所以现在的主流做法是引入时序数据库。常见的有 TDengine、InfluxDB、IoTDB开源版本都够用。我用 TDengine 比较多原因是它对 SQL 的支持比较友好团队成员不用重新学一套查询语言而且数据按时间分区聚合性能比 MySQL 好一个量级。对比项MySQL时序数据库TDengine/InfluxDB数据模型行存储适合事务业务列式时间分区适合时序曲线写入性能万级/秒需要分库分表十万级/秒基本无压力聚合查询大表 group by 时间明显变慢按时间窗口预聚合秒级返回数据保留策略需要自己写清理任务内置自动过期删除运维成本常规 DBA 即可单机版即可集群稍复杂选型结论如果测点数在 500 个以下又想少引入一套组件MySQL 也能撑两年。但只要是奔着长期运营去做的我建议一开始就上时序库省得以后数据量上来再迁移。迁移这种活最耗人力而且容易丢数据。数据链路这一层想清楚了后面选源码、搭平台才有依据。3. 基于源码搭建能源管理平台开源选型与最小可用系统数据链路摸清了下一步才是选平台。现在开源社区里能搜到不少能源管理系统、EMS 相关的项目质量参差不齐。这一章讲怎么筛源码、怎么把最小系统跑起来以及怎么把第 2 章读到的电表数据真正写进库里。3.1 选源码三看采集协议覆盖面、二次开发语言、数据模型选开源 EMS 项目我一般不看功能列表有多少只看三个硬指标。第一看采集协议覆盖面。能源管理系统最贵的是接入成本如果项目只支持 Modbus而现场还有 DL/T645 电表、BACnet 空调系统那你接到一半就会发现要自己写协议解析工作量直接翻倍。优先选把采集做成了插件化框架的项目新增协议只需要写一个插件而不是改主流程。第二看后端技术栈。项目用什么语言写的直接决定你的团队能不能二次开发。市场上常见的有 Java Spring Boot 系、Python 系、Go 系。选团队最熟的那套别因为某个项目界面好看就硬上。后面改需求时你会发现部署容易改代码难。有个客户当时选了一个界面很漂亮的纯前端 demo 项目结果后端只有接口 mock最后整个业务逻辑都要重写等于从零开始。第三看数据模型。这一步最容易被忽略但也最关键。好的 EMS 项目数据模型一定把“测点”和“设备”分开一个设备可以挂多个测点测点有统一的编码规则和单位定义。如果项目里设备表和测点表混在一起或者单位写死不能配置这个项目接到手就是坑因为现场电表的单位、倍率、量程千差万别。顺着这个思路筛下来基本能把 80% 的“玩具项目”排除掉。剩下真正能用的再进入部署环节。3.2 用容器把平台跑起来一个最小系统的 docker-compose 编排确定源码之后最常见、最可靠的部署方式是用 docker-compose 把平台服务编排起来。一个最小可用的能源管理平台至少包含数据库、后端服务、前端页面、采集服务四个组件。下面是我通常用的一个最小编排文件平台安装方案按这套走基本不会出大问题。version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ems2024 TZ: Asia/Shanghai volumes: - ./mysql-data:/var/lib/mysql ports: - 3306:3306 ems-backend: build: ./backend environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql depends_on: - mysql ports: - 8080:8080 ems-frontend: build: ./frontend ports: - 80:80 depends_on: - ems-backend collector: build: ./collector volumes: - ./collector-config:/app/config depends_on: - mysql这套编排里mysql 的 volumes 是关键数据卷必须挂出来否则容器重建一次数据就全没了这是很多新手第一次部署后找不到后悔药吃的地方。TZ 环境变量设成 Asia/Shanghai不然平台上的时间戳会比北京时间差 8 个小时后面报表对账全是错的。collector 把配置目录挂载出来方便改串口参数、轮询周期不需要重新构建镜像。跑起来的命令很简单在项目根目录执行 docker compose up -d然后看日志 docker compose logs -f。正常启动后前端页面通过浏览器访问 80 端口就能看到登录页。后端和采集服务各自的配置项不同项目差异较大但记住一个原则先让链路通再调参数。也就是先把一条真实数据从电表读到库里确认落库了再去做界面上的美化。提示生产环境不要用 root 密码跑数据库也不要让数据库端口对公网开放。这个在后面避坑章节会专门展开。3.3 把电表数据写进库一条数据的完整旅程平台跑起来后核心就是把第 2 章的 Modbus 读取结果写进数据库。这里给一段我常用的 Python 采集入库脚本它做的事情是读电表、拼接 SQL、幂等写入。import time import pymysql from datetime import datetime conn pymysql.connect(hostlocalhost, userems, passwordems2024, databaseems) cursor conn.cursor() while True: # 这里省略 minimalmodbus 读取细节假设已经拿到以下数值 meter_id MT-001 voltage 380.2 power 45.6 energy 12345.67 ts datetime.now() sql ( INSERT INTO meter_data (meter_id, ts, voltage, power, energy) VALUES (%s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE powerVALUES(power), energyVALUES(energy) ) cursor.execute(sql, (meter_id, ts, voltage, power, energy)) conn.commit() time.sleep(15) # 15 秒采一次分钟级统计由平台聚合这段代码的核心是 ON DUPLICATE KEY UPDATE它保证了同一块表、同一时刻的数据重复写入时不会产生脏行。这一点在采集链路不稳定时特别重要网络抖动导致网关重发数据如果不用幂等写入库里就会出现重复记录月底统计电度的时候数字会虚高。时间戳的处理也需要注意。这里直接用了 datetime.now()但多台采集服务器部署时各机器时钟如果不一致数据的时间轴就是乱的。常见做法是在采集服务的配置里强制指定 NTP 服务器把服务器时间对齐后再谈数据准确性。轮询间隔这里设 15 秒适合单块表的测试链路。生产环境一般按分钟级采集具体间隔取决于平台需要展示的粒度秒级采集对存储成本的压力会成倍上升。4. 把核心功能做厚分项计量、同环比分析与告警规则采集链路通了源码也跑起来了这时候的 EMS 还只能算一个“高级抄表系统”。真正让它变成能源管理平台靠的是分项计量、同环比分析、告警这三个功能。这一章我把每个功能的落地思路和 SQL、规则写法直接给出来。4.1 分项计量把总表拆成照明、空调、动力三路分项计量是能源管理的第一个刚需老板最常问的问题是“上个月车间用电多少、空调用电多少、照明多少”。做法分两种一种是物理分项每路支线单独装电表数据准确但成本高另一种是软分项在总表下按支路计量点拆分单元通过在数据表里维护 branch 字段实现。不管哪种做法落到数据库里都是同一个模式每块表带一个 branch 标识查询时按支路聚合。下面这条 SQL 可以统计任意一天每个分项的用电量。SELECT DATE_FORMAT(ts, %Y-%m-%d) AS day, SUM(CASE WHEN branch lighting THEN energy ELSE 0 END) AS lighting_kwh, SUM(CASE WHEN branch hvac THEN energy ELSE 0 END) AS hvac_kwh, SUM(CASE WHEN branch power THEN energy ELSE 0 END) AS power_kwh FROM meter_data WHERE ts 2024-06-01 AND ts 2024-07-01 AND meter_id MT-001 GROUP BY day ORDER BY day;这里 branch 的取值要与设备台账模块联动而不是在 SQL 里把值写死。实际项目中分支标识应该由后台配置新接入电表时选择所属分项即可。要注意电度表的数据通常是增量累计值不是当刻功率。因此 SUM 之前必须先把同一块表的相邻两条记录做差值得到这一周期的实际用电量再去按 branch 聚合否则结果是错的。这个差值计算可以在采集服务里完成也可以在 SQL 里用 LAG 窗口函数做推荐前者因为采集服务里做可以顺便把异常跳变过滤掉。分项汇算完之后还有一个必做动作分项之和与总表核对。常见做法是每天跑一个对账任务分项电量之和与总表电量偏差超过 2% 就告警。别小看这个校验很多项目的分项数据长期不准确就是因为没人做这个核对等月底对不上账了才回头查。对账不光是技术动作更是管理动作它逼着运维团队把每个计量点的倍率、变比、归属都搞清楚。4.2 同环比分析两个容易被问住的统计口径同环比是能源管理平台上面向管理者的核心指标。同比是今年 6 月对比去年 6 月环比是本月对比上月。SQL 写起来不难难的是口径统一。下面这一段把今天和昨天的日用电量放在同一行里对比是环比最小可用的实现。SELECT today.d AS day, today.kwh AS today_kwh, yesterday.kwh AS yesterday_kwh, ROUND((today.kwh - yesterday.kwh) / yesterday.kwh, 4) AS day_over_day FROM (SELECT DATE(ts) AS d, SUM(energy) AS kwh FROM meter_data WHERE ts CURDATE() GROUP BY DATE(ts)) today LEFT JOIN (SELECT DATE(ts) AS d, SUM(energy) AS kwh FROM meter_data WHERE ts DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND ts CURDATE() GROUP BY DATE(ts)) yesterday ON today.d yesterday.d;实际做报表时有两个口径陷阱。第一是工作日对比休息日。工厂周一和周日、商场工作日和周末的负荷结构完全不同拿周一和周日比没有参考意义。我一般会在对比维度里加一个“是否工作日”的标签当月环比也按工作日/休息日分开统计。第二是温度修正。空调能耗和气温强相关6 月同比 5 月上升 15% 不一定代表浪费可能是高温天数多了。对比报表里最好同时显示制冷度日数或平均气温给管理者一个解释的抓手。否则光靠一个百分比数字能源管理员很难向老板交代清楚“为什么用电涨了”。4.3 告警规则固定阈值怎么设才不会变成“狼来了”告警是 EMS 里最容易做砸的功能。原因很简单固定阈值设得太紧就天天误报设得太松就形同虚设。我在做告警模块时的做法是“滑动平均值加偏差倍数”也就是不拿当前值和固定值比而是跟最近一段时间的正常水平比。下面给出一段规则引擎里的判断逻辑示例。WINDOW 24 # 最近 24 个采集周期 THRESHOLD 1.5 # 当前值超过滑动平均值的 1.5 倍才告警 COOLDOWN_MINUTES 30 # 同一测点 30 分钟内不重复告警 def check_alert(history, current): avg sum(history[-WINDOW:]) / len(history[-WINDOW:]) if current avg * THRESHOLD: return True, f功率 {current:.1f} kW 超过近期均值 {avg:.1f} kW 的 {THRESHOLD} 倍 return False, 这里的 WINDOW 和 THRESHOLD 是两个必须调参的地方。WINDOW 决定了“正常水平”的样本量太短会被瞬时波动带偏太长又反应迟钝24 个点对我做过的工厂项目来说是比较稳的起点。THRESHOLD 先设 1.5观察一周的误报和漏报情况再调。有的项目还要求低谷时段的告警阈值单独放宽需要在规则引擎里加上时段判断比如夜间允许功率降到更低的水平再触发“负载异常下降”。告警除了阈值还有一个容易被忽视的机制冷却时间。假设某台空压机故障功率跌到 0如果不加冷却时间告警系统会在每个采集周期都发一条消息一晚上就能刷上千条。加了 COOLDOWN 之后同一条告警在 30 分钟内只发一次运维人员才有精力去处理真正的问题。告警这关做好了平台才有“管理价值”否则就是个摆设。5. EMS 实施避坑指南丢包、对不上账、告警轰炸的五个案例这一章我把自己和同行踩过的坑整理成五个案例每个都按“现象 → 原因 → 解决”来写希望能让读者少走一遍弯路。这些年做能源管理系统我越来越相信一句话落地最大的敌人不是技术是细节。5.1 现象采集数据总缺 5 分钟链路哪一环断了项目上了三个月运维反馈 15 分钟粒度报表经常缺记录不是固定某一块表而是随机缺。查了很久才发现问题出在串口轮询上采集程序用了单线程顺序轮询 32 块电表每块表读 6 个寄存器遇到某块表响应超时就卡住后面的表全部排队等待结果这一轮的采集窗口被拉长错过了上报时间。原因是 RS485 总线上设备响应时间不一致有的旧表需要几百毫秒才返回。解决方法是把设备分组把响应速度接近的表放在同一条总线上然后给每组配置独立的采集线程并给每次读取设置超时上限。这个坑的直接教训是单总线设备别超过 20 台超时设置 500ms宁可跳表不可卡总线。5.2 现象平台统计和供电局账单对不上客户拿着月度报表质问平台显示 6 月用电 12.8 万度供电局账单是 13.5 万度差了 7000 度。逐表核对后发现问题出在互感器倍率上。车间进线电表是 100/5 的电流互感器倍率是 20但采集配置里倍率填成了 1。电压、电流、功率这些瞬时值不受倍率影响但电度必须乘倍率导致所有带互感器的表电度全部少记。解决方法是把倍率做成设备台账字段并在部署阶段逐个和现场铭牌核对不能相信前任交接的表格。更稳妥的做法是加一道自动校验把总表电量与各分表的电量加和做对比偏差超过 2% 自动形成异常工单。这个坑在储能项目里尤其常见因为储能系统的电流大几乎全部走互感器。5.3 现象半夜告警刷屏早上没人看某园区储能项目上线后凌晨 1 点到 5 点告警系统频繁推送“SOC 过低”一晚上发了 600 多条。原因是储能 PCS 夜间按计划放电SOC 本来就是下探到 20% 再充电这个状态是正常工况但告警阈值按固定 30% 设置导致整个放电过程都在告警。解决方法是把告警规则改成“时段感知”的低谷放电时段使用低电量告警阈值并加入冷却时间。这个案例说明告警规则的设置必须由懂业务的人参与不是研发自己拍脑袋定的。储能 EMS 的判断逻辑和工厂配电完全不同拿一套固定规则套所有场景最终结果就是告警被运维直接静音。5.4 现象平台部署在公网后被陌生人扫描一个项目把 EMS 平台的 80 端口直接映射到了公网方便客户远程访问。上线两周服务器 CPU 经常 100%查日志发现大量来自境外 IP 的扫描和暴力破解尝试。原因是平台管理端没有做访问控制运维后台也暴露在公网上。解决方法是把平台回收到内网远程访问统一走堡垒机必要时才临时开放端口如果一定要公网访问至少做三层防护HTTPS、IP 白名单、登录失败锁定。能源数据属于生产数据这个安全的坑强烈建议提前考虑别等出了事再补救。尤其是采集服务它要连现场串口设备和数据库绝对不能暴露在公网。5.5 现象换了一块电表采集就断了项目运行半年后客户现场更换了一块故障电表换了同型号的新表结果这条采集链路从此不读数。原因是新表出厂默认从站地址是 1而旧表在总线上占的地址是 17地址冲突导致总线通信混乱。解决方法是把设备地址、参数做成台账换表之后必须专门做一次寻址和参数配置。后来我在所有项目里都加了一条制度设备变更必须走工单流程平台侧由管理员核对地址、倍率、协议版本后再接。玄学问题查到最后大部分都是这类配置管理问题。越是看起来莫名其妙的现象越要先怀疑配置、再怀疑硬件最后才怀疑代码。6. 从看板到调控把 EMS 接进储能与产线的进阶玩法平台跑顺之后能源管理系统EMS的价值边界才真正打开。我见过最多的进阶需求有三个第一是把 EMS 和储能系统的 BMS、PCS 联动根据峰谷电价和 SOC 自动生成充放电策略这就是“储能 EMS”的核心玩法第二是做负荷预测和需量控制提前半小时预测用电峰值触发减载策略把可中断负荷降下来第三是结合生产计划做能耗对标把单耗指标下达到每条产线。这三种玩法有一个共同的实现前提历史的分钟级数据质量稳定可靠。所以我的习惯是先让平台稳定跑两个月把数据质量过一遍再谈策略。策略本身先用离线回放验证。把过去一个月的历史数据回放给策略引擎看它生成的指令是否合理确认无误再切在线。这个习惯很重要跳过回放直接上线的团队大概率会经历一次把产线负荷误切掉的翻车现场。我做过一个简单的负荷预测验证版本用最近 14 天同时段负荷的均值做基线代码很容易跑通但已经能提前发现不少实际问题。import numpy as np # 取最近 14 天每天同时段的负荷均值作为预测基线 def predict_load(history, target_time): loads [history[d][target_time] for d in history if target_time in history[d]] return float(np.mean(loads)) # 预测值超过需量上限则触发减载 if predict_load(history, 14:30) 850: print(建议 14:20 提前启动柴油机削减市电需量)这段代码只是预测的基线版本生产环境一般会用更完整的时序模型但思路是一样的预测不是目的提前决策才是。这么多项目做下来我的个人教训是EMS 的价值不在大屏有多好看而在数据能不能经得起月底对账策略能不能在关键时刻不乱动。先把数据搞准再谈模型希望帮到你。本文还有配套的精品资源点击获取