零碳园区零碳管理系统详细说明书

文档版本：V4.0　　适用对象：园区管委会、平台建设方、系统集成商、运维运营方

编制依据：工信部《工业企业和园区数字化能碳管理中心建设指南》（工信厅节〔2025〕13号）所列12项标准功能；T/JES 020—2026《零碳园区碳管理系统数据接入技术规范》；GB/T 32150、GB/T 24067、ISO 14064-1等核算标准；国家发改委等三部门零碳园区建设通知中单位能耗碳排放≤0.2吨CO₂/吨标煤、绿电直供比例≥50%的核心指标要求。

1 系统定位与设计原则

1.1 系统是什么，不是什么

本系统是零碳园区的能碳数据底座与运营控制中枢，承担三项不可替代的职能：算得准（碳排放核算可核查、可追溯）、看得见（能耗碳排实时透明）、调得动（源网荷储与负荷侧可协同调控）。它不是一块可视化大屏，也不是孤立的碳排计算器。脱离实时数据采集和调控执行能力的“碳核算软件”，无法支撑0.2吨/吨标煤这一硬约束的动态管理。

1.2 三条设计原则

第一，核算边界先于功能设计。 系统的数据模型和核算引擎必须按照园区已确定的核算边界来构建——园区范围、纳入企业清单、能源流路径、排放源分类，在系统上线前完成结构化定义，并作为不可轻易变更的“基准配置”锁定。

第二，0.2是系统内部的“计算常数”，不是报表上的一个数字。 单位能耗碳排放≤0.2吨CO₂/吨标煤必须嵌入每一次核算运算中，作为预算控制、预警触发和调度决策的硬约束条件。系统在任何时点的“当前单位能耗碳排放”都是可计算、可对比、可触发动作的。

第三，绿电的“绿色属性”必须可溯源到小时级。 绿电直供比例≥50%的达标认定，不能依赖月度或年度电量比例。系统须具备小时级发电—用电匹配和不可篡改存证能力，使每一度被计为零排放的电力都有带时间戳的绿电来源凭证。

2 功能规格

功能设计以工信部指南12项标准功能为骨架，叠加零碳园区特有的硬指标校验、绿电溯源和调控执行能力。以下按“监测—核算—预算—溯源—调度—资产—报告”七个功能域展开，不逐条对应12项功能清单，而是按系统实际运行逻辑组织。

2.1 全介质能耗监测与数据质量管控

采集范围覆盖电、水、气、热、冷、光伏发电、储能充放电、充电桩负荷等全部能源介质，按“园区—片区—楼栋—企业—产线—重点设备”六级粒度组织数据。

电力数据采集周期≤5秒，水气热数据≤15分钟，关键计量点（关口表、绿电直连计量点、储能PCS出口）应达到分钟级或更高频。系统须内置数据质量引擎：对跳变、缺失、越限、计量反向等异常自动标记并触发补采或人工复核；所有修正操作留痕，确保用于碳核算的每一笔数据都满足“可核查、可追溯”要求。数据完整率目标≥99.9%。

与常规能耗平台的实质区别：本系统对“外购电力”和“绿电直连电力”实施分表计量、分路采集、分时打标。绿电直连计量点须同时记录发电侧出力和用电侧受电，为后续小时级匹配提供两侧数据基础。

2.2 碳排放核算引擎

核算引擎须同时支持园区级、企业级、产品级三个层次的排放计算。

园区与企业级核算：按范围一（直接排放，含固定燃烧、移动燃烧、逸散排放、工业过程）、范围二（外购电力和热力）、范围三（上下游间接排放，按园区实际数据可得性分步纳入）组织核算模型。外购电力排放因子使用全国化石能源电力排放因子0.8325 kgCO₂/kWh作为默认值，但须支持按省域、按小时动态更新；经绿电直连或绿证交易获取并完成溯源匹配的电量，排放因子计为0。

产品级碳足迹核算：内置符合GB/T 24067和ISO 14064-1的核算模型，支持从产品BOM和工艺路线反推活动数据，对接企业ERP/MES获取产量和物料数据，生成产品碳足迹报告。因子库应至少覆盖园区主导行业的主要产品类别，并支持用户导入自定义因子。

0.2硬约束的嵌入方式：核算引擎在每次园区级核算完成后，自动计算“单位能耗碳排放”（吨CO₂/吨标煤），并与0.2阈值比对。该结果同时写入三个下游功能：预算管理模块据此判断剩余碳空间，预警模块据此触发分级警报，调度模块在生成优化方案时将其作为约束条件之一。

2.3 用能与碳排放预算管理

预算管理解决的是“还剩多少碳空间可用”的问题。系统按年度、季度、月度三个时间粒度，以园区和企业两个层级，将0.2目标反推为可支配的碳排放预算总量，并分解到各用能单元。

核心机制包括：预算编制（基于历史排放、产能计划、绿电供应预测生成初始预算方案）；实时扣减（实际排放从预算额度中动态扣减）；滚动预测（根据当前进度和剩余时间预测期末达标概率）；预算调整（在绿电供应条件变化或产能重大调整时，经审批后调整预算分配）。当任一单元的预算消耗速率超过时间进度对应的阈值时，系统推送预警并建议干预措施（增加绿电消纳、调整生产时序、启动需求响应等）。

2.4 绿电溯源与小时级匹配

这是零碳园区系统区别于通用能碳平台的核心功能，直接支撑“绿电直供比例≥50%”的达标认定和出口企业碳足迹的绿色属性证明。

系统按以下链路实现绿电溯源：发电侧数据接入（光伏逆变器、风电SCADA、绿电直连计量点）→ 小时级发电曲线生成 → 用电侧分时负荷匹配（将园区各企业/各计量点的用电量按小时与发电曲线进行匹配）→ 未匹配电量处理（区分“已匹配绿电”“未匹配网电”“储能转移绿电”三类）→ 存证与凭证生成（匹配结果上链存证，生成带时间戳的小时级绿电消费凭证）。

关键设计约束：匹配粒度应不低于1小时；区块链存证用于确保数据不可篡改和可审计；凭证须包含发电来源、时段、匹配电量、对应用电方等字段，可直接用于CBAM碳足迹申报的绿电属性证明。储能系统的充放电应记录“充入电力来源”，放电时按来源比例分配绿色属性，避免绿电属性在时间平移中丢失或虚增。

2.5 源网荷储协同调度与需求响应

系统应具备从“监测”走向“调控”的能力，但调控范围须在方案阶段明确：是只做到“建议调度”，还是具备向储能PCS、充电桩、可调负荷下发指令的闭环控制权限。建议按“先建议、后闭环、再自治”三阶段演进。

日前调度：基于负荷预测（融合历史数据、天气、生产计划）、光伏出力预测和分时电价/碳因子，生成次日储能充放电计划和可调负荷时序建议。实时调度：当实际运行偏离日前计划时，按“绿电消纳优先—成本优化—碳排约束”的优先级实时修正。需求响应：接收电网邀约后，自动筛选可调资源（储能、充电桩、中央空调、非连续工业负荷），估算可响应容量，生成申报方案；响应执行过程实时监测，执行结果自动记录并用于收益结算。

系统须预留与虚拟电厂平台的标准化接口。内部资源应满足“可观、可测、可调、可控”要求，实时运行数据（有功/无功、状态、可调容量）按虚拟电厂管理规范的要求上送，调度指令按预定义协议接收并拆解执行。

2.6 碳资产与绿证管理

碳资产模块不是简单的台账记录，而应覆盖“持有—交易—履约—收益”的完整链路。管理对象包括碳配额、CCER、绿证及其他碳信用。核心功能：碳资产台账（持仓、到期、交割、结余）；交易记录与市场信息接入（CCER、绿证、碳配额价格）；履约管理（配额清缴进度跟踪、缺口预警）；收益核算（将碳资产收益分摊至园区/企业层级）。绿证管理须与绿电溯源模块联动：绿电消费凭证可作为绿证核发或交易的底层依据，绿证持有和消纳情况应反映在园区绿电占比计算中。

2.7 报告生成与合规输出

系统应能一键生成面向不同用途的报告：碳核查支撑报告（满足第三方核查的数据颗粒度和审计追踪要求）、零碳园区自评估报告（对照单位能耗碳排放、绿电直供比例等核心指标自动填表）、产品碳足迹报告（符合ISO 14064/GB/T 24067格式）、CBAM辅助申报数据包（含小时级绿电凭证、产品碳排放强度）。所有报告的数据来源须可追溯到原始计量记录。

3 数据接入规范

3.1 接入对象与接入方式

接入对象分为五类：能源计量数据（智能电表、水表、燃气表、热量表、流量计）、生产运行数据（PLC/DCS/SCADA、MES/ERP中的产量、物料、工艺数据）、环境监测数据（温湿度、空气质量，服务于负荷预测和碳汇核算）、绿电绿证数据（发电侧出力、绿电直连计量、绿证/CCER持有与交易记录）、碳汇与碳抵消数据（园区绿化碳汇、碳信用注销凭证）。

接入方式按实时性分为四类：实时采集（电力关口表、绿电计量点、储能PCS，周期≤1分钟）、批量上传（企业ERP/MES数据，按日或按批次）、第三方平台集成（电力交易平台、碳市场登记系统、虚拟电厂平台，通过API对接）、人工录入（碳汇参数、碳信用凭证等低频结构化数据，须附证明材料并留痕）。

3.2 通信协议与传输要求

现场设备层应兼容DL/T 645、Modbus、MQTT、OPC UA、IEC 60870-5-104、BACnet等主流协议；平台间接口采用HTTPS/JSON或WebService，符合等保三级对数据传输加密和身份认证的要求。边缘网关应具备断网本地自治能力：与云端通信中断时，继续完成数据采集、本地存储和关键控制逻辑，恢复后断点续传，保证数据完整性。

3.3 数据质量控制

用于碳核算的数据须满足：准确性（计量器具在检定周期内，数据偏差不超过标准允许范围）、完整性（关键计量点数据缺失率低于设定阈值，缺失时自动标记并触发补采）、一致性（同一数据在不同层级汇总时保持一致，口径可追溯）、时效性（按约定周期到达平台，超时告警）、可追溯性（原始数据、修正记录、审核记录全程留痕）。任何对碳核算结果有影响的数据修改，须经过“申请人—审核人—生效”的受控流程。

4 技术架构

系统采用“云—边—端”三层协同、数据层与业务层解耦的架构。

端侧：标准化智能仪表、传感器、采集终端，覆盖全部能源介质和关键设备。端侧设备应支持即插即用和远程配置，减少现场调试工作量。

边缘层：在配电房、能源站、绿电计量点等关键节点部署边缘计算网关，完成协议转换、数据清洗、本地告警和关键控制指令的本地执行。边缘层是调度闭环“最后一公里”的执行保障——当云端下发储能充放电或负荷调节指令时，边缘网关负责安全校核和指令落地。

平台层：承载数据中台和业务应用。数据中台包括时序数据库（能耗/碳排实时数据）、关系数据库（资源档案、核算配置、碳资产台账）和图数据库（电碳耦合关系、绿电溯源链路）。业务应用按微服务或模块化方式部署，支持按园区规模弹性扩展。

关键设计选择：核算引擎和调度引擎应作为独立服务部署，与前端展示解耦。核算规则、排放因子、调度策略的更新不应导致前端停机或数据中断。模型组件层（负荷预测、光伏预测、调度优化）以容器化方式管理，便于迭代和A/B验证。

5 接口规格

5.1 内部接口

与园区微电网/储能EMS的接口：双向。上行获取储能SOC/SOH、充放电功率、可用调节容量；下行下发充放电计划或实时功率设定值。协议优先采用IEC 60870-5-104或厂商开放的API，控制指令须带确认回执和执行状态反馈。

与楼宇自控（BA）系统的接口：通过BACnet或OPC UA获取空调、照明、水泵等柔性负荷的运行状态和可调能力，下行下发温度设定调整、时段控制等指令。接口设计须明确“可调负荷基线”的约定算法，作为需求响应效果核算的依据。

5.2 外部接口

与虚拟电厂平台的接口：按虚拟电厂管理规范要求，上送资源模型（类型、容量、可调范围）和实时运行数据（有功/无功、状态、可用调节量），接收调度指令和收益结算信息。接口须建立版本管理和接口台账。

与电力交易/绿电交易平台的接口：用于获取绿电交易合同、成交电量、分时价格和绿证划转信息，作为绿电溯源和碳核算的输入。建议优先采用交易平台提供的数据订阅或文件交换方式，避免高频轮询。

与碳市场登记/交易系统的接口：用于碳配额持仓和履约状态查询、CCER持有与注销记录同步。碳交易执行环节通常需要在登记系统或交易所完成，系统侧重台账管理和数据同步，不宜直接嵌入交易下单功能（除非有明确的安全合规安排）。

与政府监管平台的上报接口：按属地主管部门要求的数据格式和频次，生成能耗/碳排上报数据包。接口设计应保持可配置，以适应不同地区、不同时期的上报口径变化。

6 非功能要求

性能：实时数据从端侧采集到平台可查询的端到端时延≤200ms（电力数据）；碳核算单次园区级全量计算在分钟级完成；系统可用率≥99.9%。绿电小时级匹配的计算任务须在整点后规定时限内完成，不影响下一时段的调度决策。

安全：满足网络安全等级保护三级要求。碳核算数据、绿电溯源存证记录、碳资产台账的访问须实施最小权限控制；所有数据修改和审批操作记录不可篡改的审计日志。区块链存证节点的部署方式（自建、联盟链、依托国网链等）须在方案阶段明确，并评估长期可维护性。

可维护性与可扩展性：核算因子库、调度策略参数、报告模板支持配置化管理，不需要开发介入即可更新。新增计量点或新增接入企业的操作应控制在“配置级”而非“开发级”。系统架构应支持从“园中园”扩展到园区全域，从单一园区扩展到多园区集团化管理，而不发生架构性重构。

7 实施与验收要点

7.1 分期上线策略

不建议一次性全功能上线。建议第一期（约3—4个月）完成数据采集层、碳排放核算引擎和基础监测看板——先让数据“准起来”，验证核算结果与园区现有统计口径的一致性，这是后续一切功能的前提。第二期（约4—6个月）上线绿电溯源、预算管理和报告生成，打通绿电数据的采集—匹配—存证链路。第三期（约3—4个月）上线调度控制和虚拟电厂接口，在局部场景（如储能充放电、充电桩有序充电）完成闭环验证后再推广。

7.2 验收的核心判据

验收不应以“功能是否上线”为标准，而应以数据可信度和核算准确性为标准。至少完成以下验证：园区级核算结果与第三方核查（或主管部门认可的上一年度排放数据）的偏差在可接受范围内；绿电小时级匹配的存证记录可被独立审计复现；0.2指标的实时计算结果在模拟不同绿电供应和负荷场景下行为正确；从原始计量数据到最终报告的全链路可追溯。

7.3 需要特别规避的三个陷阱

其一，先建大屏、后补数据。 可视化是数据可信之后自然产生的能力，数据底座不牢时的大屏只是装饰。其二，绿电溯源做成“月度电量比例”的变体。 小时级匹配的技术复杂度远高于年度比例计算，但这是出口企业碳足迹认证和绿电直供合规认定的实际要求，不能在方案阶段降级处理。其三，调度功能在数据质量未经验证时贸然闭环。 基于错误数据的自动调度指令，其风险高于人工操作。闭环控制必须以至少一个完整核算周期的数据质量验证为前提。

说明书的核心判断可以归结为一句话：零碳管理系统的价值不在于“管了多少数据”，而在于它能否让园区在任意时点回答三个问题——当前的碳排放离0.2还有多远、用的每一度绿电是否经得起溯源审计、下一小时应该怎么调用度和碳。三个问题都能被系统持续、可靠地回答，系统就是合格的。