MyEMS白皮书
| 项目 | 内容 |
|---|---|
| 文档名称 | MyEMS 开源能源管理系统白皮书 |
| 副题 | 以计量关系为核心的能源与碳核算底座 |
| 版本 | 6.10.0 |
| 日期 | 2026 年 10 月 |
| 编制单位 | 北京海识软件有限公司（https://hassoft.cn） |
| 开源社区 | https://myems.cn |
本白皮书依据公开资料、《MyEMS 开源能源管理系统架构设计文档》与源码仓库信息编写。文中的官方陈述、文档事实与作者推算已分级标注，测算口径与假设见正文说明。
内容提要
制度的约束口径已经从吨标准煤转向吨二氧化碳当量。国办发〔2024〕39 号明确“十五五”时期以碳排放强度作为约束性指标，全国碳市场在 2025 年 3 月扩围至钢铁、水泥、铝冶炼三个行业，新增约 1500 家重点排放单位、约 30 亿吨二氧化碳当量，并要求月度存证与三级数据审核。能耗、成本、碳排三条账第一次被同一套制度同时追问。
多数企业并不缺系统，缺的是核算。看板能显示实时曲线，却说不清一块表属于谁、一段消耗算给谁、按什么口径折算、出错时怎么改。白皮书把这一差距收敛成六项判断标准：对象模型、点位绑定、数据质量、口径变更、多维聚合与可迁移性。三项以上不达标，系统就只是监测工具。
MyEMS 以七类对象共用一套聚合结果、三条核算链共用一份能耗值、十三个数据库按用途分层的方式回答这些问题。这套结构用共享数据库与预计算换来部署轻量、离线可用与结果可复核，用固定维度换来跨项目交付的一致性；它定位在以日、月为管理周期的单项目深度核算，秒级闭环控制与贸易结算级计量由专业系统承担。
收益与边界写在同一份结构里：报表滞后一个时段，换来查询只扫窄表、响应与数据量弱相关；维度扩展要新增物化表，换来一次配置可复用到全项目；前端双栈与多库兼容带来维护投入，换来跨库交付与国产数据库适配的自由度。把八项技术决策的收益与边界一并写进立项文件，比在功能清单上打勾更能降低失败概率。
钱的大头不在软件。示例项目投资 100 万元，计量改造占四成、实施服务占三成半；在年电费 1700 万元、节能率 3% 至 8% 的情景下，静态回收期为 2.1 年至 0.8 年。项目成败最终取决于三件事：计量是否到位、口径是否冻结、是否有人 真正接手。
第一章 白皮书说明
一、这份文件要回答的问题
关于 MyEMS 的中文材料已经不少。官网用一页篇幅列出社区版与企业版的功能差异，源码仓库用 README 说明组件构成与部署方式，架构设计文档把 11 个组件、13 个数据库和四类组件契约逐条写清。材料齐全并不等于判断容易。一个准备立项的用能单位真正要回答的，是这些能力与自己的账目如何对应，以及为了获得这些能力要接受哪些限制。
白皮书围绕四个问题展开。
- 环境。 碳排放双控接替能耗双控、全国碳市场从发电行业扩围到钢铁、水泥、铝冶炼之后，企业对能源数据的要求发生了什么变化。
- 现状。 已经装了监测系统、已经能在大屏上看到实时曲线的单位，为什么仍然算不清分摊、对不上账单。
- 方案。 MyEMS 用什么结构回应前两个问题，这套结构又要求使用者放弃什么。
- 落地。 一个具体项目怎样从计量改造走到可验收的报表，投入与收益如何估算。
四个问题对应十一章。第一至第三章建立判断背景，第四至第七章说明方案与代价，第八至第十章处理实施、算账与选 型，第十一章收束风险与结论。产品介绍放在中间而不是开头，因为不了解制度约束与核算难点的读者，很难判断一份功能清单里哪些条目是必要的。
二、证据来源与可信度分级
白皮书的材料分四类，可靠程度不同，使用方式也不同。先看来源，再看边界。来源决定一条结论能不能进入立项文件，边界决定它能被引用的范围。文档事实可以直接对照代码与表结构，读者一旦发现不一致，应以源码为准；官方陈述能证明某种能力或案例存在，但不能据此推断项目成功率；作者推断是把前两类事实放进成本与容量模型后的结果，换个假设，结论就会变。
| 证据等级 | 来源 | 在本白皮书中的用法 | 需要注意的边界 |
|---|---|---|---|
| 文档事实 | 《MyEMS 开源能源管理系统架构设计文档》，v6.9.0，2026 年 10 月 | 组件构成、数据库划分、接口契约、部署参数 | 描述代码组织与结构，不含生产环境实测 |
| 政策原文 | 国办发〔2024〕39 号、生态环境部行业扩围工作方案及答问 | 制度环境与合规要求 | 只引用已公开发布内容 |
| 官方陈述 | 官网功能清单、社区版与企业版对照表、Gitee 仓库页面 | 功能范围、版本节奏、许可、项目案例与认证 | 由维护方发布，未经第三方独立核验 |
| 作者推断 | 本白皮书的性能判断、成本模型与情景测算 | 形成决策区间 | 均为带假设的估 算，需现场复核 |
对实施人员来说，这四类材料的使用场景也不同。架构文档适合在配置与排障时查阅，政策原文适合在编写方案与验收条款时引用，官网功能清单适合在需求澄清阶段比对，测算模型适合在投资评审时做敏感性分析。把它们混在一起使用，最容易出现的错误是把官方陈述当作技术事实，或者把作者推断当作政策要求。
分级不是为了给材料排座次，而是让读者知道一条结论在哪一步可能失效。架构文档中的表结构与端口可以直接用于实施，因为它描述的是代码；官网上的项目案例数量可以作为市场验证的参考，但它由维护方统计，白皮书不把它换算成成功率；成本模型里的每一个系数都来自公开报价区间或行业经验，读者应当用自己项目的询价替换。
文中凡属推算的数字都注明“估算”，凡属政策口径的表述都给出文件名称与发布时间，凡属维护方自述的内容都标注来源。
三、口径、时点与适用边界
白皮书以社区版 v6.9.0 为基准。项目保持每月一个小版本、每年一个大版本的发布节奏，累计发行版 49 个。版本迭代会改变界面、配置项乃至表结构，本文涉及具体字段与端口的内容以架构文档为准，工程实施时应回查对应版本的建表脚本与升级说明。
性能与容量部分给出的是可复核的量级推算。文中行数增长、单表规模与任务耗时，均从表结构、采集周期与调度方式推导，足以判断扩容压力落在采集侧还是报表侧；正式的性能承诺建议在试运行阶 段用采集行数曲线与任务耗时曲线标定。
政策部分截至 2026 年 10 月。碳排放双控的制度框架已由国办发〔2024〕39 号确定，全国碳市场在 2025 年 3 月完成首次行业扩围，后续仍有化工、石化、民航、造纸等行业的扩围准备。读者在项目实施年度引用政策时，应核对最新的重点排放单位名录、核算指南与配额方案。
白皮书不评价具体项目的节能量。节能量的测算依赖基线年的选取、影响因素归一与计量边界，同一套数据在不同边界下可以得出差别很大的结论。第九章给出的是方法框架与情景算法，不是可以照搬的节能率。
四、发布立场与使用声明
MyEMS 由北京海识软件有限公司开发维护，该公司同时以按项目收费的方式提供企业版与技术服务。本白皮书的技术事实主要来自其公开的架构文档与官网，作者在引用时尽量保持口径，并在涉及商业能力时区分社区版与企业版。读者应当知道这一层关系：维护方有推广产品的动机，白皮书的可用之处在于它同时写明了产品的适用边界，读者可以据此判断这套系统与自己的场景是否匹配。
白皮书不构成采购建议、技术承诺或对第三方的评价。文中的方案比较只按公开可验证的维度展开，不涉及具体厂商的报价与商务条件。涉及商标、代码许可与二次开发归属的内容，以 MIT 许可原文、官网声明与合同约定为准。
读者若发现文中事实与源码、官方文档不一致，应以源码与官方文档为准，并把差异记录到项目评审材料中。文档与代码之间存在时间 差，能回到代码验证的人才有把握。
五、阅读路径
| 读者 | 建议阅读 |
|---|---|
| 决策者 | 第一、二、三、九、十章。前三章建立为什么必须做、现有方案为何不够的判断，第九章回答钱的问题，第十章给出与其他方案的比较和决策清单 |
| 技术负责人 | 第四至第七章。版本、许可与社区版边界，能力矩阵，五层架构与十三个数据库，八项技术决策换来的能力与边界 |
| 实施与运维人员 | 第五、六、八、九章。第八章的六阶段路径与验收口径最接近现场，第六章的部署与契约部分决定排障效率 |
| 二次开发者 | 第五、六、十章，并直接查阅仓库中的组件说明与 API 手册 |
第二章 能源管理的制度环境与经营约束
一、约束口径从能耗转向碳排
2020 年 9 月，中国宣布二氧化碳排放力争于 2030 年前达到峰值、努力争取 2060 年前实现碳 中和。此后，考核口径发生了一次不容易被察觉但影响深远的迁移：过去以吨标准煤衡量节能，现在以吨二氧化碳当量衡量降碳。2024 年 7 月 30 日，国务院办公厅印发《加快构建碳排放双控制度体系工作方案》（国办发〔2024〕39 号），明确提出建立能耗双控向碳排放双控全面转型的新机制。方案对“十五五”时期的表述是，将碳排放强度降低作为国民经济和社会发展约束性指标，开展碳排放总量核算，不再将能耗强度作为约束性指标。
这句话对能源管理系统的含义比看上去更重。吨标准煤是一个按能源种类固定的折算口径，一度电折算多少标准煤由系数表决定，年度之间变化不大。碳排放则要区分直接排放与间接排放，要区分电力排放因子随电网结构变化带来的年际差异，还要在产品碳足迹核算中把外购电、外购热、燃料燃烧与工业过程分别归集。同一份用电数据，在能耗口径下是一条曲线，在碳排口径下至少要拆成“用电量、排放因子、排放归属”三段，并且每段都要能追溯到时间和来源。
方案同时要求健全企业节能降碳管理制度，把碳排放管控要求纳入重点用能单位管理制度，加强能源和碳排放计量器具配备与检定校准。碳核算的起点不是报表，而是计量。没有可信的分表计量，任何碳报表都只是把总表数字按比例分摊。
二、碳市场把数据质量变成现金流
2021 年 7 月，全国碳排放权交易市场以发电行业为突破口启动上线交易。2025 年 3 月，经国务院 批准，钢铁、水泥、铝冶炼三个行业纳入全国碳市场，新增重点排放单位约 1500 家，新增覆盖排放量约 30 亿吨二氧化碳当量，扩围后全国 60% 以上的二氧化碳排放纳入管控。扩围方案把 2024 至 2026 年度定为启动实施阶段，2027 年度以后进入深化完善阶段，并提出到 2027 年基本覆盖工业领域主要排放行业。
数据在这个市场里是直接定价的。截至 2025 年 6 月 30 日，全国碳市场配额累计成交量 6.69 亿吨，成交额 459.3 亿元，2024 年全年成交额 180.44 亿元。配额按排放强度分配，排放强度低于行业基准的企业产生盈余，高于基准的企业需要购买。核算偏差不再只是报表误差，而是盈亏。
扩围方案还规定了月度存证与“国家—省—市”三级数据质量审核。重点排放单位要按月把化石能源消费量等关键参数留痕，接受技术审核。对系统的直接约束是：数据必须可按月封存、可回溯到原始计量、可证明没有被事后修改。很多企业的现状是，月度报表由 Excel 汇总，原始数据留在采集电脑上，一旦核查人员追问某个异常月份的明细，就要花一周时间倒查。
直接排放与间接排放的区分同样值得注意。三个扩围行业管控的是化石燃料燃烧与工业过程产生的直接排放，不覆盖外购电力、热力导致的间接排放。但企业碳管理、绿色工厂评价、产品碳足迹仍然需要间接排放数据，绿电采购与绿证交易也会改变间接排放的算法。系统因此要能同时维护两套口径，而不是在其中一套里做近似。
三、能源成本的结构性压力
电价机制的变化比政策文件更早影响到财务。分时电价把一天切成尖、峰、平、谷若干时段，需量电价按最大需量或变压器容量计费，功率因数不达标还要承担力调电费。商业综合体与园区还要面对租户分摊：同一块总表下的多个租户，按面积、按分表、按合同约定比例分摊，规则随租约变化。
这些规则都不是“用电量乘单价”。分时电价要求系统在汇总阶段按小时段落匹配费率，需量电费要求系统能取出时段内的最大负荷，力调电费要求系统掌握无功电量。用户拿到的账单因此是复合结果，任何一环算错，争议都会落到能源管理部门而不是财务部门。
分布式能源的接入让问题更复杂。屋顶光伏的发电量要先抵自用再谈余电上网，储能的充放电存在效率损失，充电桩的用电要单独计量并向运营方结算。一个园区内同时存在购电、发电、售电、储能四类流向时，成本核算已经接近一个小型的能量平衡问题。
四、管理标准给出的框架与缺口
GB/T 23331-2020《能源管理体系 要求及使用指南》等同采用 ISO 50001:2018，2020 年 11 月 19 日发布，2021 年 6 月 1 日实施，现行有效。标准要求组织完成能源评审、建立能源基线、识别能源绩效参数、设定能源目标与指标、制定行动计划，并通过测量与分析验证改进效果。
标准给的是管理框架，不是数据模型。它规定“应当能够测量和验证”，却没有规定表计如何编号、分摊如何留痕、基线如何重算。实际项目中，这一空缺由系统填补：系统的对象模型决定了能否表达“这台冷机属于哪个冷站、这个冷站服务哪几栋楼、这几栋楼的租户如何分摊”，系统的核算链决定了能否在电价调整后重算历史账单。
标准审核中最容易被质疑的环节是能源基线。基线年的数据往往来自手工台账，影响因素归一的方法写在报告里而不是系统里。把基线、变量、修正系数放进系统，是让管理体系从文档走向可验证的关键一步。
五、由此推导出的五项硬要求
- 可追溯。 任何一个能耗、成本或碳排数字，都要能回溯到具体的计量表、数据点与时间段，而不是只回到一张汇总表。
- 可核算。 能耗、成本、碳排三条链共用一份能耗值，系数可替换，历史可按时间段重算。
- 可比较。 支持同比、环比、基准期对比与单位面积、单位产品两类强度指标，也支持总分表平衡校验。
- 可审计。 坏数据要留下标记而不是被悄悄修掉，口径变更要留下记录而不是覆盖历史。
- 可运维。 系统要能在企业内网、离线环境与国产化软硬件上稳定运行。
能画实时曲线、能做大屏，只是第一项要求的最低配；能算清分摊、能在核查时拿出证据、能在政策口径变化后重算，才是这套尺子真正衡量的东西。满足这五项要求需要付出存储与建模成本：多维聚合要预物化，历史要分层保留，质量标记要贯穿全链路。
第三章 现有能源管理系统的结构性缺口
一、看板型系统与核算型系统的分界
多数用能单位并不缺系统。电表接了、网关装了、大屏亮了，值班室能看到各回路的实时功率，手机上能收到超限告警。真正的困难出现在月底：能耗分摊要人工算，电费账单对不上，集团要的单位面积能耗口径各部门不一致，核查人员要某个点位的原始数据时没人能立刻拿出来。
这条分界线不在界面上，而在对象模型里。看板型系统以“回路”或“测点”为中心，回答的是“现在多少、刚才多少”；核算型系统以“计量关系”为中心，回答的是“这块表属于谁、这段消耗算给谁、按什么口径折算、出错时怎么改”。前者把数据画出来，后者把数据算清楚。
二、协议与数据的碎片化
现场的仪表从来不是一家。配电室的多功能表多是 Modbus RTU 或 Modbus TCP，暖通设备走 BACnet/IP，生产线控制器是 西门子 S7，新建的能源站可能提供 OPC UA 服务端，老旧设备只有 RS485 串口。楼宇自控系统往往由不同厂商在不同年代建设，接口开放程度不一。
各套软件的时间基准不同，点表命名不同，数据分别落在不同电脑上，跨系统的对比就无法进行。某一路采集程序崩溃后，那一段数据永久缺失，而报表层看不出缺口。判断一套系统是否真正解决了这个问题，可以看两件事：新增一种协议时，是否需要改动上层的分析与报表逻辑；点位地址、采集周期这类参数，能否在管理界面配置而不必改代码。
三、重监测、轻核算
曲线与告警是能源管理系统的可见部分。核算所需的不可见部分包括计量表台账、点位与表的绑定关系、能源分类与能耗分项、分摊规则、电价与账单、能耗基线与计划。常见的失真是由小到大累积的：总表与分表之差无人解释；换表当天的累积量归零，被当成负消耗计入；电价从单一制改为分时制后，历史账单没有重算；新增一个车间，直接在报表工具里加一列，没有回到对象模型里登记。
核算型系统会给坏数据打标，让报表同时给出数值与可信度；看板型系统通常选择滤波或人工改正，改完就再也说不清哪些值被动过。
四、封闭与绑定
商业能源管理系统常见的授权方式是按点位、按模块、按并发用户计价。扩容时边际 成本陡然上升：增加点位要补授权，增加报表模块要另签合同，想接自有的财务系统要买接口包。数据资产无法沉淀为自己可复用的模型；更换供应商时，历史数据与配置难以迁移。
开源许可解决的是退出成本，不是实施能力。MIT 协议允许商用、修改与再分发，意味着企业可以自己养团队维护、可以把系统部署在任意环境、可以在项目结束时带着代码离开。它不保证有人帮你把表接对。
五、组织维度单一
同一度电既属于某个配电回路，也属于某栋楼、某个租户、某家门店、某个车间，还可能属于某个由多台设备组成的冷站。只按空间一个维度组织的系统，能回答“这栋楼用了多少”，回答不了“这家门店每平方米用了多少”“这个租户本月该付多少”“这个冷站每制取一冷吨需要多少电”。这些要求对象模型从一开始就支持多对多归属。
六、可审计性弱
可审计性包含三层：原始数据是否可按点位与时间段取出，数据处理过程是否有标记，口径与配置的变更是否有痕迹。多数系统的薄弱点集中在第二层与第三层。坏数据被算法自动修正且不留标记；电价或排放因子被直接改成新值，历史报表随之改变；谁改了配置、什么时候改的，没有操作日志。
七、交付与运维依赖原 厂
能源管理系统的生命周期通常长于建设合同。依赖多个中间件、依赖特定操作系统、依赖公网访问的系统，在企业内网与离线环境中往往水土不服。一套系统能否被本单位接管，是比功能清单更实际的指标：让本单位的工程师在没有原厂在场的情况下，完成一次新增数据源、一次修改电价、一次按时间段重算。
八、六项判断标准
| 判断项 | 看板型系统的典型表现 | 核算型系统的要求 |
|---|---|---|
| 对象模型 | 以回路与测点为中心，空间层级靠命名区分 | 空间、计量表、设备、租户、门店、车间、组合设备七类对象，多对多归属 |
| 点位绑定 | 点表在采集软件里，分析端另建一套映射 | 数据点归属计量表或设备，绑定关系是唯一真源 |
| 数据质量 | 异常值被滤波或人工覆盖，不留标记 | 越限、缺失、倒走可标记，报表同时给出可信度 |
| 口径变更 | 直接改历史值或改配置，无版本可回溯 | 系数变更后按时间段重算，变更过程留痕 |
| 多维聚合 | 只按空间或回路汇总，分摊在 Excel 完成 | 按对象、方向、分类、粒度预物化，报表直接读取 |
| 可迁移性 | 数据与配置绑定厂商，迁移成本高 | 支持 JSON 导入导出、REST 接口与标准数据库 |
六项中若有三项以上落在中列，说明现有系统更接近监测工具而不是核算工具。此时继续在原系统上叠加报表，通常只能缓解表面问题，无法解决口径与追溯。
第四章 MyEMS 的定位、沿革与开源治理
一、定位：把计量关系当作一等公民
MyEMS 是面向用能单位的开源能源管理系统，参照 GB/T 23331-2020（等同采用 ISO 50001:2018）的能源管理体系要求设计，覆盖建筑、工厂、商场、医院、园区与能碳管理中心的电、水、气、冷、热等能源数据，并支持能耗、成本、碳排放三条核算主线。官方资料显示其已积累上千个项目案例并通过 CMA 检测认证，代码以 MIT 协议开源。
与通用组态软件或纯数据平台相比，MyEMS 的重心不在画面组态，而在计量关系的建模。空间、计量表、设备、租户、门店、车间、组合设备七类对象共用同一套聚合结果，使同一份能耗数据可以按组织维度、物理维度与商业维度同时展开。
系统不承担 SCADA 画面的深度组态，不承担贸易结算级的计量检定，也不内置消息中间件与流式计算引擎。跨组件的数据交换以数据库表为介质，实时性以采集周期为单位 。
二、沿革、版本节奏与工程规模
仓库当前发行版为 v6.9.0，累计发布 49 个发行版，标签 51 个，提交记录 6138 次。Gitee 页面显示星标 2.7K、分支 890、关注 275，Issues 7 个、待合并 PR 2 个。语言构成中 Python 占 96.7%，HTML 占 3.0%，SCSS 占 0.3%。
项目保持每月一个小版本、每年一个大版本的节奏。功能在持续变化，升级需要按 CHANGELOG 与升级文档执行库结构变更。数据库结构在本系统中具有接口地位，跨版本升级必须先读升级说明，再在测试环境验证。
v6.9.0 周期内，采集侧形成 Modbus TCP、BACnet/IP、西门子 S7、OPC UA 四个独立服务，另提供离线表与 Excel 导入通道；计算侧固定为规范化、清洗、汇总三个服务。
三、许可边界与合规要点
MyEMS 采用 MIT 许可，允许商用、修改、再分发，也允许闭源衍生。官网对社区版附加了一条限制：使用者必须保留 MyEMS 相关版权信息及 LOGO，不得修改或删除；更换品牌名称与标志属于社区版明确不支持的能力。企业版可以按项目授权谈品牌定制。
集成商把系统嵌入自研平台时，如果替换了登录页 LOGO、改了浏览器标题、去掉了页脚标识，就触及了社区版的限制条款。合规的做法是把品牌诉求走企业版授权，或者在界面外层保 留 MyEMS 标识与版权声明。商标与代码许可要分开看，MIT 授予的是代码权利，不授予商标使用权。
MIT 许可不提供任何担保。社区支持以 QQ 群、微信群为主，响应时间与深度无法与商业 SLA 相比。
四、社区版与企业版的能力分布
两版共享同一套架构与主干能力，差异集中在协议覆盖、行业纵深与交付保障。企业版能力需以合同约定为准。详见社区版与企业版功能清单。
| 能力域 | 社区版 | 企业版（按项目授权） |
|---|---|---|
| 采集协议 | Modbus TCP、BACnet/IP、Siemens S7、OPC UA，另含离线表与 Excel 导入 | 增加 Modbus RTU、OPC DA、IEC 61850、IEC 101/103/104、楼控厂商 API、数据库与 MQTT/Kafka 接入 |
| 基础分析 | 计量表、空间、设备、租户、门店、车间、组合设备的能耗、成本、碳排、负荷、效率、统计与比较分析 | 增加节能分析、计划分析、碳足迹分析，依赖能耗预测与能耗计划组件 |
| 报表输出 | 页面报表、真实 xlsx 导出（含图表对象）、AI 分析结论 | 增加高级报表模板、定时生成与邮件分发、组态图形工具 |
| 能源设施 | 以用能侧计量与核算为主 | 增加光伏、储能、充电桩、微电网、虚拟电厂、储能与光伏电站监控 |
| 诊断与控制 | 故障诊断库与消息表结构存在，AI 分析提供建议 | 增加 FDD 能效故障诊断、设备远程控制、工单管理 |
| 数据发布 | REST 接口、JSON 导入导出 | 增加 BACnet Server、Modbus TCP Server、OPC UA Server、MQTT 发布、Kafka Producer |
| 部署与数据库 | docker-compose；MySQL、MariaDB、Percona、SingleStore、OceanBase 等 MySQL 系产品 | 增加 K8s 部署，SQL Server、Oracle、PostgreSQL 支持 |
| 品牌定制 | 禁止更换名称与标志 | 可按项目授权定制 |
对多数以“采集—分析—报表”为主线的项目，社区版已经够用。选型时应先判断项目是否落在社区版边界内，再决定是否需要企业版。
五、上千案例、认证与可持续性判断
官网与仓库都把“上千个项目案例、CMA 检测认证、承诺永久开源”作为核心信号。这三项属于维护方陈述，白皮书不独立核验。案例数量说明系统在多种现场条件下被部署过；检测认证通常针对特定功能或性能指标，具体范围需要向维护方索取报告；永久开源是治理承诺，其约束力取决于维护方的持续投入。
MyEMS 的维护主体是北京海识软件有限公司，核心提交集中在少数维护者。集中式治理的优点是方向稳定、版本节奏可控、商业支持有明确责任人；风险是单点依赖。
对使用者的实际建议是把“能否自行维护”写进选型条件。项目交付时应取得完整代码、建表脚本、升级文档与本地构建方式，并在自己的代码托管平台保留一份分支。
六、开源能解决什么，不能解决什么
开源的直接价值是降低许可成本与退出成本，间接价值是让二次开发有据可依。需要项目侧承担的部分同样明确：现场计量改造的质量、点位绑定的准确性、口径与业务的匹配、运维人员的接手能力。这些属于项目实施范畴，与代码是否开源无关。
第五章 能力体系：六个功能域与能力边界
一、采集接入域：把协议差异压缩成配置
四个采集服务各管一种协议，服务本身不解释业务，只做协议解析与类型转换；点位属于哪块表、哪台设备，由配置库中的 object_type 与 object_id 决定。新增一种协议时，只需按同一骨架复制实现，上层的规范化、汇总与报表不必改动。
采集配置被压缩成两段 JSON。数据源的 connection 保存主机、端口与采集周期，例如 10.9.67.99、502 端口、60 秒；点位的 address 保存从站号、功能码、寄存器起始偏移、寄存器数量、数据格式与字节交换开关，功能码支持 01、02、03、04 与 23。现场调试因此可以在管理界面完成。
配置在服务启动时载入内存，修改数据源或点位后必须重启对应服务。实施时应把“改配置、重启服务、核对数据”固化为标准动作。对无法联网或需要人工抄录的计量点，系统提供离线表与 Excel 导入两条通道。
二、监测分析域：七类对象与多个时间尺度
空间、计量表（含离线表与虚拟表）、设备、组合设备、租户、门店、车间七类对象共用同一套聚合结果，每类对象都提供能耗分类、能耗分项、成本、碳排、负荷、效率、统计与比较分析。时间尺度提供小时、日、月、年四档，比较方式提供同比、环比、自由比与不比。
计量表层另有实时分析、总分表平衡、批量分析与电能质量分析。空间层提供仪表盘、能流图与配电系统分析。强度指标按单位面积值或单位产品值考核，前者要求维护建筑面积，后者要求把产品、班组、班次与产量登记到生产库。
三、核算域：三条链与三类派生
能耗 、成本、碳排放共用一份能耗值，差别只在系数。能耗值乘以电价得到成本，乘以排放因子得到碳排。改电价、改因子，重跑对应时段即可，不必重新采集。
分时电价、阶梯电价、需量电费、力调电费无法用单一系数表达，必须在汇总时解析。产品内置的示例数据中，电的折算因子为 0.123 千克标准煤每千瓦时与 0.928 千克二氧化碳每千瓦时。这组数值属于示例口径，实施时必须按项目所在地重新维护。
基线库、计划库与 8760 小时模型库依赖历史聚合值，属于二级派生。社区版提供存储与分析入口，节能分析、计划分析与能耗预测的完整功能在企业版中按项目授权提供。
四、报表输出域：真实表格与可调度报表
导出由服务端用 openpyxl 生成真实的 xlsx 文件，内含表格与曲线图、柱状图、饼图对象。页面级报表由前端调用分析接口渲染；高级报表由报表定义驱动，支持模板文件、定时生成与邮件分发。二者共用同一套聚合数据。
页面报表读取的是已物化的聚合表，响应时间与数据量弱相关，而与所选时段和对象数量相关。一旦需求超出预置维度，请求就会退化为对历史库的扫描。这类需求应通过新建物化表或独立分析库解决。
五、配置管理域：界面字段即表字段
配置端承担空间树、计量表与数据点、数据源与协议、设备与组合设备、成本中心、电价、工作日历、用户与权限等主数据维护。Admin UI 基于 AngularJS 1.x，字段与后端表结构几乎一一对应。绝大多数运行参数存在数据库或环境变量中，备份数据库就备份了业务配置。
六、扩展域：AI 分析与行业纵深
社区版已提供基于 DeepSeek 与 OpenAI API 的人工智能分析，把聚合数据交给模型生成分析结论与节能建议。模型不掌握现场工况、设备状态与工艺约束，结论必须由人复核后才能进入改造决策。
企业版把能力延伸到光伏电站、储能电站、充电桩、微电网、虚拟电厂、风电场、电能质量监测，以及设备远程控制、FDD、工单、组态图形、移动端与重点用能单位数据上传。近期版本还在 MCP 服务器、LLM 函数调用与 AI Skill 方向布局。
七、能力矩阵与能力边界
| 功能域 | 核心能力 | 主要使用者 | 项目侧通常需补齐 |
|---|---|---|---|
| 采集接入 | 四类工业协议、离线表、Excel 导入、数据源与点位配置 | 实施工 程师、运维 | 现场仪表与网关、网络改造、点表核对 |
| 监测分析 | 七类对象的分类分项、负荷、效率、统计、比较、总分表平衡、电能质量 | 能源管理员、值班人员 | 对象台账、面积与产量数据、分析口径约定 |
| 核算 | 成本折算、碳排折算、基线、计划、8760 模型 | 能源管理者、财务 | 当地电价、排放因子、基线年选择 |
| 报表输出 | 页面报表、真实 xlsx 导出、高级报表模板与定时分发 | 管理层、集团报送 | 报表模板、报送口径、邮件网关 |
| 配置管理 | 空间树、计量表、数据点、设备、电价、权限、工作日历 | 系统管理员 | 编码规则、权限分级、备份制度 |
| 扩展 | AI 分析结论；企业版的光储充、微电网、FDD、控制与工单 | 分析人员、运维班组 | 设备接口、控制策略、安全评估 |
系统在“算准”和“查得清”上投入最多，在画面组态与实时控制上投入最少。
第六章 技术架构：五层、十三库与两条链路
一、五层结构与进程级隔离
系统在逻辑上分五层。采集层把现场信号变成库中的原始值，存储层按用途持有原始值、聚合值与派生值，计算层按时间节拍把原始值加工为多维口径的能耗、成本与碳排，服务层以 REST 接口对外提供查询、计算与导出，展示层按角色分为分析端与管理端。权限、配置、多语言、日志、容器化与多库适配作为横向支撑存在。
采集层与计算层的每个组件都是独立进程或独立容器，可以单独启停、单独扩容。某个采集协议异常不会拖垮接口服务。组件之间没有直接的进程间调用，全部通过库表耦合。
| 组件 | 运行形态 | 主要技术栈 | 核心职责 | 默认端口 |
|---|---|---|---|---|
| myems-database | 初始化脚本集 | MySQL DDL | 创建 13 个库与全部表、初始数据 | 无 |
| myems-api | 常驻服务 | Python、Falcon、gunicorn 或 waitress、openpyxl | REST 接口、鉴权、报表与 Excel 导出 | 8000 |
| myems-admin | 静态站点 | AngularJS 1.x、nginx | 主数据与采集配置管理 | 8001 |
| myems-web | 静态站点 | React 16、ECharts、Chart.js、i18next、nginx | 能源数据分析与可视化 | 80 |
| myems-modbus-tcp | 常驻采集 | Python、modbus_tk、schedule | Modbus TCP 与 RTU 数据采集 | 无 |
| myems-bacnet | 常驻采集 | Python、BACnet/IP | 楼宇自控设备采集 | 无 |
| myems-opc-ua | 常驻采集 | Python、OPC UA | 从 OPC UA 服务端取数 | 无 |
| myems-s7 | 常驻采集 | Python、S7 协议 | 西门子 PLC 采集 | 无 |
| myems-normalization | 定时计算 | Python、mysql-connector、schedule | 原始值转换为小时能耗值 | 无 |
| myems-cleaning | 定时计算 | Python、schedule | 坏数据识别、修正与标记 | 无 |
| myems-aggregation | 定时计算 | Python、mysql-connector | 多维多粒度汇总与派生核算 | 无 |
采集与计算服务不监听端口。防火墙规划时，只放通 80、8001、8000 与 3306 是不够的，采集容器还需要一条到现场设备网段的路由。
二、领域模型与归属链
领域模型的核心是一条归属链：数据源产生数据点，数据点归属计量表或设备，计量表归属空间并绑定能源分类，空间通过父指针构成树，树上再挂门店、租户、车间等业务子类。组合设备把多台设备与计量表聚合为一个系统。
实体表内不冗余存储关联列，多对多关系一律由独立关联表承载。系统也不为每类对象建独立的事实表族，而是复用同一套聚合表命名规则。“某楼层本月的照明用电”要经过空间树递归、关联表展开、能耗分项过滤三步，这也是系统大量使用预聚合而非实时 JOIN 的原因。
三、十三个数 据库与四层数据
| 分组 | 数据库 | 用途 | 规模特征 |
|---|---|---|---|
| 配置 | myems_system_db | 能源分类、分项、空间、计量表、设备、组合设备、数据点、数据源、成本中心、电价、配电系统、能流图、命令 | 表最多，约 150 张，数据量小、关系复杂 |
| 配置 | myems_user_db | 用户、权限、会话、API 密钥、操作日志、通知 | 小，安全要求高 |
| 原始 | myems_historical_db | 原始时序值与最新值缓存，含离线表、成本、修复、计划四类文件表 | 数据量最大，按点与时标增长 |
| 聚合 | myems_energy_db | 多维能耗聚合，按小时、日、月、年物化 | 行数由对象与维度组合决定 |
| 聚合 | myems_billing_db | 成本聚合，结构与能耗库一致，值已按电价折算 | 与能耗库同构 |
| 聚合 | myems_carbon_db | 碳排放聚合，结构与能耗库一致，值已按因子折算 | 与能耗库同构 |
| 派生 | myems_energy_baseline_db | 能耗基线，用于节能效果对比 | 较小 |
| 派生 | myems_energy_model_db | 8760 小时年度能耗模型 | 每对象 8760 行 |
| 派生 | myems_energy_plan_db | 能耗计划与目标值 | 较小 |
| 派生 | myems_energy_prediction_db | 能耗预测值 | 较小 |
| 支撑 | myems_fdd_db | 故障诊断规则与多通道告警消息 | 小 ，规则表达式复杂 |
| 支撑 | myems_reporting_db | 报表定义、模板文件、生成文件与邮件 | 小，含二进制附件 |
| 支撑 | myems_production_db | 产品、班组、班次与产量 | 小 |
数据按加工深度分为四层。L0 是历史库中的原始点值，只增不改；L1 是历史库中按计量表口径归集的能耗值；L2 是能耗库中按对象、方向、分类与粒度物化的聚合值；L3 是计费库、碳排库、基线库、计划库、预测库与模型库中的派生值。
系数变化只涉及 L3；计量表归属变化要从 L1 起重跑；只有采集错误才需要回到 L0 补数再逐层重算。
四、计算链路与时间节拍
一条数据从现场到报表要走七个环节：现场读取、协议解析、原始入库、规范化、清洗、汇总、查询呈现。
规范化是口径的第一次收口。计量表与点位绑定错了，错误会一路传导到成本与碳排，且不会在任何环节报错。清洗处理越限、缺失与倒走三类异常，先归集再清洗的顺序不能颠倒。汇总按对象与维度计算能耗，按电价计算成本，按因子计算碳排，三件事共用一次能耗读取。
采集是分钟级，规范化、清洗与汇总是小时级，报表是请求级。报表看到的最新数据通常滞后一个时段。这一滞后是设计使然。
五、组件间契约与接口设计
时间统一以 UTC 存储，历史表用 utc_date_time，聚合表用 start_datetime_utc。数值统一使用 DECIMAL(21,6)。标识统一为自增 id 加 uuid。质量与状态用 is_bad、is_published、is_counted、is_enabled 四个布尔位。
接口遵循 REST 风格。所有请求携带用户标识与令牌，程序化集成可用 API 密钥替代，失败返回 401。权限以用户为粒度，支持管理员、只读与自定义三档，没有组织级的行级隔离。任意配置对象都提供导出与导入端点，导入时按 uuid 对齐对象。
六、部署形态与现场接入
系统提供 docker-compose 与 systemd 原生安装两条路径，组件构成一致。
典型部署由应用主机、数据主机和现场网络三部分组成。应用主机暴露 80 与 8001，8000 与 3306 收敛在内网。接口与管理端必须挂载同一 upload 目录，否则模板文件在接口侧不可见。
采集侧建议双网卡或独立采集网关：一侧连 IT 网络，一侧连 OT 网络，两侧之间不做路由转发。只有串口的仪表需要现场部署 Modbus RTU 转 TCP 网关。
部署后按“接口版本、登录、打开任一分析页、检查一条采集数据”四步验证。
七、非功能设计与可靠性保障
报表请求只做范围过滤与求和。以 3000 个数据点、15 分钟采集为例，单日新增 28.8 万行，年增约 1.05 亿行，按每行 40 字节含索引估算，年增约 3.9 GiB；采集周期缩短到 1 分钟，年增放大 15 倍。以 500 个对象、4 种粒度、2 个分类维度估算，小时粒度年增约 438 万行。（估算）
组件崩溃后重启即可恢复。单机部署的数据库是唯一需要外部保障的环节。默认口令必须在首次登录后修改，接口限流与 TLS 由反向代理承担，数据库账号应按最小权限划分。系统不具备完整的等级保护要求的日志留存、双因素认证与数据脱敏能力。
建议监控三类指标：按点位统计最近写入时间，按粒度统计最新时段，对接口版本与关键查询测响应时间。
第七章 关键设计取舍与适用边界
一、八项决策与它们换来的能力
| 决策 | 系统的选择 | 理由 | 取舍与应对 |
|---|---|---|---|
| 集成方式 | 组件间以共享数据库表耦合，不引入消息中间件 | 部署简单、离线可运行、不增加运维对象 | 表结构即契约，变更即跨组件不兼容；整体升级并回读升级说明 |
| 采集方式 | 按周期轮询，采集与计算之间不互相通知 | 实现简单、对设备无侵入、适配老旧仪表 | 实时性受周期约束；缩短关键点位周期或另建高速通道 |
| 计算位置 | 规范化、清洗、汇总以小时批处理预物化 | 报表快、算力需求低、结果可复核 | 口径变更需重算；用分区与增量重算控制影响面 |
| 数据组织 | 十三个库按用途分离，聚合库同构 | 边界清晰、便于按重要性分别备份 | 跨库无外键，一致性靠应用保证 |
| 数据库适配 | 多库兼容，只用共有 SQL 子集 | 可部署在 MySQL 系、SQL Server、Oracle、PostgreSQL | 无法使用窗口函数、JSON 函数、原生分区语法 |
| 时间与数值 | 统一 UTC 与 DECIMAL(21,6) | 跨时区一致、避免浮点误差 | 本地日历边界要在展示层校正 |
| 权限模型 | 用户级权限，无组织级行级隔离 | 模型简单、实现与运维成本低 | 多租户隔离依靠空间树与视图；敏感场景应独立部署 |
| 前端技术 | 分析端 React，管理端 AngularJS 1.x | 分析端保持现代体验，管理端保持稳定 | 双栈维护成本，AngularJS 已结束官方长期支持 |
系统用共享数据库与预计算换来部署轻量、离线可用与结果可复核 ，用固定维度与统一口径换来跨项目可复用的核算结果。
二、交换之一：结构简单与实时性
组件之间不通过 API 或消息队列通信。没有消息中间件要运维，一套 docker-compose 就能在一台机器上跑起来。实时性由采集周期与计算节拍共同决定。常见采集周期为 60 秒至 15 分钟，规范化、清洗与汇总按小时执行。用户看到的最新数据通常滞后一个时段。
以日月为管理周期的分项计量、分摊、考核与报送，落在这条边界内。秒级负荷控制、需量预测联动、微电网并离网切换、故障录波，落在边界外。告警规则按周期评估，存在分钟级延迟。毫秒级联锁应由现场保护装置完成。
三、交换之二：预计算与口径变更
聚合表按对象、方向、分类维度与粒度四个要素组合。500 个对象、4 种粒度、2 个分类维度，一年约 438 万行小时级数据。（估算）新增维度需要新增表与汇总任务。电价或排放因子变更后，历史是否重算需要业务决策。
系数变化从派生层重跑，归属变化从规范化层重跑，采集错误才回到原始层补数。配置库宜每日全备，原始库按分区增量备份，聚合与派生库可重建。
四、长期维护：前端双栈与多库兼容
AngularJS 1.x 在 2021 年底结束官方长期支持。只做配置维护的项目，管理端很少改动；需要频繁调整管理界面的项目，双栈成本会快速显现。多库兼容只能使用各库共有的 SQL 子集。这套系统更适合建好之后稳定运行、改造集中在数据与报表侧的项目。
五、适用画像与边界条件
| 项目特征 | 建议定位 | 理由 |
|---|---|---|
| 单一园区、厂区、医院或商业体的私有化部署 | 优先推荐 | 单机拓扑即可覆盖，运维边界清晰 |
| 内网或离线环境，不允许访问公网 | 优先推荐 | 无外部服务依赖，镜像与依赖可离线准备 |
| 预算敏感，希望把许可费转为实施与计量投入 | 优先推荐 | MIT 许可无许可费，成本集中在现场与人力 |
| 有租户、门店、车间多维核算需求 | 优先推荐 | 七类对象共用聚合结果，分摊与评比可落地 |
| 点位规模千级至万级，管理周期为日、月、年 | 优先推荐 | 采集与汇总节拍匹配，容量在单机可承受范围 |
| 需要二次开发或与自有系统集成 | 优先推荐 | 代码、表结构、REST 接口全部可见 |
| 需要秒级闭环控制或联锁保护 | 边界之外 | 轮询采集与小时批处理无法满足实时性 |
| 用于贸易结算或计量检定 | 边界之外 | 系统未做计量法制相关认证，精度责任在表计 |
| 多租户 SaaS 或超大规模集中部署 | 边界之外 | 无组织级行级隔离，单库写入存在瓶颈 |
| 要求等级保护三级以上、涉密环境 | 可配套补齐 | 缺少双因素、完整审计留存与数据脱敏，需自行加固 |
| 需要复杂组态画面与工艺动画 | 边界之外 | 组态图形工具在企业版，深度有限 |
| 单位无运维能力且要求 7×24 原厂响应 | 可配套补齐 | 社区支持以群组为主，SLA 需另签服务 |
六、立项评审要确认的五件事
- 能否接受报表滞后一个时段。
- 计量改造的预算与时间是否落实。
- 数据库高可用由谁负责。
- 谁在两年后接手。验收时应把这项能力作为交付物之一。
- 是否需要品牌定制。集成商若以自己的品牌交付，应提前走企业版授权。
第八章 典型场景与实施路径
一、五类场景的侧重点
园区与商业综合体的核心矛盾是分摊。总表、分表、租户表构成三层计量，公共区域能耗要按约定规则摊到租户。哪些回路进总表、哪些进分表、哪些作为公共，必须在装表之前定下来。
工厂与绿色工厂的核心矛盾是归属。能耗要落到车间、产线与产品。前提是生产库中的产品、班组、班次与产量被持续登记。产量靠月底补录时，单位产品能耗只能按月算。
医院的核心矛盾是连续性。重点是关键回路的实时监测、告警与历史追溯。后勤往往由多家服务商分责，权限划分要比其他场景更细。
连锁门店的核心矛盾是可比性。必须统一计量口径、面积口径与营业时长修正。任何一家门店的特殊化都会破坏可比性。
能碳管理中心的核心矛盾是汇聚与口径。碳排因子要按年度版本管理，报送口径要能对应主管部门的表格。企业版提供重点用能单位数据上传。
二、六阶段实施路径
| 阶段 | 主要工作 | 交付物 | 典型失败模式 |
|---|---|---|---|
| 立项与边界 | 明确管理目标、核算口径、覆盖范围与验收标准 | 需求说明书、计量点位清单、验收条款 | 目标写成“建设 能源管理平台”，无法验收 |
| 计量与台账 | 现场勘查、补装或更换表计、建立对象台账 | 表计台账、空间树、能源分类与分项表 | 表计与台账不同步，上线后大面积返工 |
| 采集与联调 | 部署系统、配置数据源与点位、逐点核对 | 点位对照表、采集完整性报告 | 点位地址错位，数据看似正常实则错表 |
| 口径与试运行 | 冻结电价、因子、分摊规则，跑通三条核算链 | 口径说明、试运行报表、差异分析 | 口径反复调整，历史数据无法对齐 |
| 验收与培训 | 按验收条款逐项验证，交付文档与培训 | 验收报告、运维手册、培训记录 | 只验功能不验数据 |
| 运维与优化 | 监控采集与聚合、处理异常、迭代报表 | 运维日志、月度数据质量报告 | 无人接手，系统在半年后停止更新 |
计量与台账必须先于采集，口径必须在试运行前冻结，培训必须在验收前完成。
三、验收口径与判定方法
| 验收项 | 判定方法 | 常见争议 |
|---|---|---|
| 采集完整性 | 随机抽取 20 个点位，核对最近 7 天每小时是否有值，缺失率低于约定阈值 | 通信中断导致的缺失是否计入考核 |
| 点位绑定正确性 | 对每个抽检点位做一次人为负荷变化，观察对应曲线是否同向变化 | 多回路共用表计时归属难以判定 |
| 总 分表平衡 | 选取 3 个典型日，计算总表与分表之和的差值率 | 线损与未计量部分是否允许存在 |
| 单位与折算 | 核对能源分类的单位、折标系数、排放因子与当地口径一致 | 示例因子未替换导致系统性偏差 |
| 报表口径 | 抽取月报、年报各一份，与手工台账逐项比对 | 报表时段按 UTC 还是本地日历切分 |
| 导出文件 | 打开导出的 xlsx，检查表格数值与图表对象是否完整 | 图表数据与表格数据不一致 |
| 权限与审计 | 用只读账号尝试修改配置，检查操作日志是否记录 | 日志留存周期不满足内审要求 |
| 性能 | 按最大对象数与最长时段执行一次查询与导出，记录耗时 | 验收数据量与生产数据量不一致 |
验收时应要求提供一份因子配置清单，并抽查三个能源分类的换算结果。
四、组织与角色
用能单位一侧需要能源管理员、信息化或自动化人员、财务或采购人员。实施方一侧需要项目经理、采集工程师、数据分析与培训人员。电价规则、分摊规则与碳排放因子应在试运行前由三方在同一张确认单上签字。
用于贸易结算、政府报送或补贴申请的数据，必须来自经检定的计量器具。系统数据可以作为管理依据，但不能替代经检定的读数。
五、数据质量治理
每日检查采集连续性，每周检查总分表平衡，每月检查小时、日、月三层聚合是否推进到最新时段。人工修正必须填写原因与依据；坏数据时段应显示缺口而不是补零；计量表更换必须登记更换时间与新表底数。电价、因子与分摊规则的变更应记录生效时间，并明确是否重算历史。
六、常见偏差与规避
- 把试点直接放大到全网。应按区域分批，每批完成后固化模板。
- 计量改造滞后于软件上线。项目计划应以计量为关键路径。
- 口径未冻结就要求出报表。
- 没有运维预算，验收后系统无人更新。
- 过度定制管理端，升级时无法合并。
第九章 投入产出与效益评估
一、成本结构：许可为零不等于投入为零
以下为一个三千点位规模园区项目的示例构成，金额为作者推断，需用项目询价替换。（估算）
| 投入项 | 金额（万元） | 主要内容 | 可控性 |
|---|---|---|---|
| 计量表计与改造 | 40 | 补装与更换约 200 只表计、通信网关、停电施工与校验 | 低，受现场条件与停电窗口制约 |
| 实施服务 | 35 | 现场勘查、点表核对、系统配置、报表开发、联调与培训 | 中，取决于实施方经验 |
| 服务器与网络 | 8 | 应用主机、数据库主机、交换机与双网卡改造 | 高，可按现有资源复用 |
| 培训与文档 | 4 | 管理员培训、运维手册、口径说明 | 高 |
| 项目管理与预备费 | 13 | 项目协调、监理、不可预见支出 | 中 |
| 合计 | 100 | 不含企业版授权与品牌定制 | — |
年度运行成本按每年 35 万元估算：技术服务 12 万元、内部运维人力 0.7 人按 21 万元计、云资源与耗材 2 万元。三年总拥有成本约为 205 万元。作为对照，按点位授权计价的商业系统在同等规模下的许可费通常在 30 万至 60 万元区间，年维保按许可费的 15% 至 20% 计。（估算）
二、收益的三条线
节能收益来自基于可见数据做出的运行调整、设备维护与技术改造，不是系统本身。示例按 3%、5%、8% 三档节能率测算，分别对应“仅做可视化与考核”“配合运行优化”“配合局部技术改造”。
成本优化更容易被财务认可。示例中需量管理约 8 万元、峰谷负荷转移保守取 12 万元、力调电费减免 4 万元、报表与对账 自动化 8 万元，四项合计 32 万元。（估算）
碳排收益目前多数项目无法直接变现。示例年用电 2000 万千瓦时，按 2022 年度全国电力平均二氧化碳排放因子 0.5703 千克每千瓦时计算，间接排放约 11406 吨。按 80 元每吨的内部碳价折算，相当于每年 91 万元的影子成本。（估算）
三、节能量怎么算
节能量依赖反事实基线。基线年通常取项目实施前一个完整自然年；若当年有停产、扩产、极端天气，需要做影响因素归一。改造前后的计量边界必须一致。只计入可归因于管理或改造的部分。系统能提供计算所需的数据与过程记录，但不能自证节能量的真实性。
四、情景测算
测算口径为年用电 2000 万千瓦时、综合电价 0.85 元每千瓦时、投资 100 万元、年运行成本 35 万元、非节能收益 32 万元，折现率 8%，不计残值。（估算）
| 情景 | 年节能率 | 年节能收益（万元） | 年净收益（万元） | 静态回收期（年） | 三年累计净现金（万元） | 五年净现值（万元） |
|---|---|---|---|---|---|---|
| 保守 | 3% | 51.0 | 48.0 | 2.1 | 44.0 | 91.7 |
| 中性 | 5% | 85.0 | 82.0 | 1.2 | 146.0 | 227.4 |
| 积极 | 8% | 136.0 | 133.0 | 0.8 | 299.0 | 431.0 |
年电费 1700 万元的项目，3% 的节能率就足以覆盖投资；年电费 500 万元时，3% 情景扣掉运行成本后净收益接近于零。三个情景都假设计量改造按期完成、口径一次冻结、运维有人接手。
五、三项容易被低估的投入
对象会膨胀：500 个对象两年后可能变成 1200 个，规划应按 2 至 3 倍预留。计量改造会超支：防爆表、隔离模块和重新布线会使单价翻倍，应先勘查再出预算。人力会被忽略：需要有人每天看采集、每周核对平衡、每月出报表、每年做口径复核。
六、什么情况下可以缓做
年电费低于 100 万元、且没有分摊与对外报送需求的单位，优先级应往后放。计量基础极差且没有改造预算的项目，应先把表装好。需要实时控制与联锁的项目，应选择控制系统。组织上无人负责、也没有考核机制的项目，系统不会产生节能。
第十章 选型比较与决策清单
一、五类可选方案
| 比较维度 | 商业能源管理系统 | 组态或 SCADA 延伸 | 通用物联网平台自研 | 时序数据库加 BI | MyEMS |
|---|---|---|---|---|---|
| 许可成本 | 高，按点位与模块阶梯计价 | 中，按点数与授权 | 中至高，按设备数与消息量 | 低，多为开源组件 | 无软件许可，实施与计量为主 |
| 协议覆盖 | 视产品而定，常见协议齐全 | 强，工控协议覆盖广 | 强，靠网关与驱动市场 | 弱，需自建采集 | 四类工业协议，企业版扩展 RTU、IEC 系列、厂商 API |
| 核算深度 | 中至高，取决于产品定位 | 低，需二次开发 | 低，模型需自建 | 低，靠人工建模 | 高，能耗、成本、碳排三条链内置 |
| 多维对象 | 常见空间加成本中心 | 以回路与设备为主 | 灵活但需自建模型 | 无主数据 | 七类对象共用聚合结果 |
| 可定制性 | 受产品边界限制 | 高，但依赖实施方 | 高，需自研能力 | 高，但工作量大 | 高，代码与表结构可见 |
| 交付周期 | 三至六个月 | 三至九个月 | 六至十二个月 | 一至三个月出首版 | 一至三个月出首版 |
| 离线与信创 | 视产品，部分需公网 | 支持内网 | 多为云原生，离线部署受限 | 支持 | 支持内网与离线，可用国产数据库 |
| 服务保障 | 有 SLA 与本地服务 | 依赖集成商 | 平台厂商 加自研团队 | 无 | 社区支持，SLA 需另签 |
| 数据可迁移 | 受厂商限制 | 取决于集成商 | 平台锁定风险 | 高 | 高，标准库表加 JSON 导入导出 |
| 规模上限 | 视产品架构 | 中小规模为主 | 大规模 | 取决于设计 | 单项目千级至万级点位 |
二、逐类判断
商业系统换来交付保障，许可费随规模上升，迁移成本高。组态延伸的画面与实时性强，核算要另做。物联网平台扩展快，业务模型要从零开始。时序库加 BI 轻，但缺主数据与核算链。MyEMS 的核算链完整、数据可带走，社区支持不等同于 SLA，实时性不适配控制场景。
三、决策清单
| 问题 | 回答为是 | 回答为否 |
|---|---|---|
| 是否需要秒级控制或联锁保护 | 选择控制系统，管理系统只做记录 | 继续判断 |
| 数据是否用于贸易结算或法定计量 | 需经检定的专用计量系统，管理系统不替代 | 继续判断 |
| 是否有租户、门店、车间等多维核算需求 | MyEMS 或具备同等对象模型的商业系统 | 轻量监测或时序库加 BI 即可 |
| 是否要求软件许可零成本且数据可迁移 | MyEMS 为首选 | 商业系统更省心 |
| 年电费是否超 过 1000 万元 | 完整系统的投资回收期通常可接受 | 需把分摊与报送价值计入，或选轻量方案 |
| 是否有内网、离线或国产化要求 | MyEMS 或支持私有化部署的产品 | 云服务方案可行 |
| 是否需要光储充、微电网、虚拟电厂能力 | 企业版授权，或另配专业系统 | 社区版主干能力足够 |
| 是否要求 7×24 原厂响应与赔付条款 | 需另签服务合同，或选商业系统 | 社区支持可接受 |
| 是否有人员能承担配置与运维 | 可自主实施，成本最低 | 需购买实施与运维服务 |
| 是否需要替换品牌对外交付 | 走企业版品牌授权 | 保留 MyEMS 标识即可 |
前两个是否决项。中间五个决定方案类型。后三个决定商务安排。
四、招标与合同建议
技术条款应明确计量边界与表计清单、核算口径与因子来源、验收方法与数据核对方式。使用开源系统时，应要求交付完整代码、建表脚本、升级文档与本地构建说明，并明确二次开发成果的归属。跨版本升级由谁执行、失败如何回滚，需要事先约定。服务等级应按数据连续性、报表时效、故障响应三项分别设定。
五、开源使用的合规要点
社区版必须保留版权信息、LOGO 与页面 标题。MIT 授予代码权利，不授予商标使用权。商用交付前应盘点依赖包许可。系统本身不向外发送数据，启用 AI 分析时会把聚合数据提交给模型服务商；敏感项目应关闭外部模型调用。
六、给三类决策者的建议
用能单位应以“能否算清账”为第一标准。集成商应把 MyEMS 作为交付底座而不是成品转售，并在报价阶段说清社区版不能换标。开发者应先读表结构再读代码，二次开发尽量在现有对象模型上扩展。
第十一章 风险应对、演进与结论
一、技术边界的应对方式
新增配置功能优先落在 React 侧，把配置端逐步迁移列为中长期任务。实时性边界不会随版本迭代消失，控制类需求应划给专业控制系统。原始库与聚合库的归档要在运行两三年后提前安排。集团级场景按项目分实例部署，或以视图隔离替代行级权限。复杂查询交给 BI 或数据仓库，而不是要求接口承担。
二、组织与社区风险
项目由北京海识软件有限公司主导，核心提交集中在少数维护者。交付时应取得完整代码与建表脚本，在自己的代码托管平台保留可运行分支，并培养两名以上能读懂表结构与配置的人员。QQ 群与微信群不承担故障赔付与响应时效。
三、合规与安全风险
需要过等保的项目应在反向代理与应用层做加固。用于贸易结算、行政监管或补贴核算的计量数据，必须来自经检定合格的计量器具。涉密或有数据出境限制的项目应关闭外部模型调用。社区版不能替换品牌，以 MyEMS 名义宣传需要许可。
四、AI 能力的现实边界
AI 分析的合理定位是辅助阅读，不是考核、投资决策或对外报告的依据。界面上应标注“AI 生成，需人工复核”，并把建议与数据依据一并呈现。企业版若让模型直接调用系统能力，权限设计应做到操作留痕、命令白名单与人工确认。
五、演进方向
未来几年的演进大概率集中 在分区与增量重算、行级隔离与组织维度、接口限流与查询能力、前端双栈收敛，以及光储充、微电网与模型调用。判断是否完成从单项目工具到集团平台的转变，可以看能否按组织隔离数据与权限、能否在不重建整库的前提下重算任意时段、能否在多点位多项目下保持采集与聚合时效。
六、结论
MyEMS 的优势集中在三处：七类对象共用一套聚合结果；能耗、成本、碳排三条链共用一份能耗值；MIT 许可加标准库表，使数据与配置可以带走。系统定位在以日、月为管理周期的多维度核算。
项目成败最终取决于三件事：计量是否到位，口径是否冻结，是否有人真正接手。准备启动项目的单位，可以从一次完整的计量盘点开始。
参考资料
- 北京海识软件有限公司．《MyEMS 开源能源管理系统架构设计文档》，v6.9.0，2026 年 10 月．
- MyEMS 官方网站。https://myems.cn，访问日期 2026 年 10 月 31 日．
- MyEMS 社区版功能清单。访问日期 2026 年 10 月 31 日．
- MyEMS 企业版功能清单。访问日期 2026 年 10 月 31 日．
- MyEMS 源代码仓库。https://gitee.com/myems/myems，访问日期 2026 年 10 月 31 日．
- 国务院办公厅．《加快构建碳排放双控制度体系工作方案》（国办发〔2024〕39 号），2024 年 7 月 30 日．
- 生态环境部等．《全国碳排放权交易市场覆盖钢铁、水泥、铝冶炼行业工作方案》及相关答问，2025 年 3 月．
- 全国碳排放权交易市场运行情况，生态环境部 2025 年 7 月发布．
- GB/T 23331-2020《能源管理体系 要求及使用指南》，2020 年 11 月 19 日发布，2021 年 6 月 1 日实施．
- 生态环境部．2022 年度全国电力平均二氧化碳排放因子，2024 年发布．
- MIT License 原文，随仓库分发．
- 国际节能量测量与验证方法体系（IPMVP）相关公开资料，用于第九章方法框架参考．