总体设计

能碳系统最常见的失败方式，不是技术选错，而是边界没定清：有人把它当电表抄表系统，有人要求它直接出碳中和报告，还有人希望它顺便接管生产排程。边界不清，表结构会反复改，硬件点位会反复加，最后谁也说不清“这个数准不准”。

这一章先把边界、角色、功能和数据流定下来。技术栈在下一章，硬件在再下一章。

1. 建设目标

一套工厂级能碳系统，通常要同时满足四类诉求：

再往上，才是碳资产、碳交易、绿电绿证、CCER、供应链碳足迹这些扩展能力。第一版不要做，除非合同明确要求。

2. 业务边界

2.1 建议纳入第一版的范围

• 能源介质：电、水、天然气、蒸汽、压缩空气。有余力再加冷/热量、氧气/氮气、光伏和储能。
• 组织层级：园区 → 车间 → 产线 → 班组。至少支持三级。
• 计量层级：园区总表、车间分表、重点设备表。总表与分表要能对账。
• 碳核算：组织级范围一、范围二；范围三做成可配置的选填项。
• 报表：日报、月报、年报、碳核算报告、异常报告。
• 对接：现有 PLC、电表、水表、燃气表；MES/ERP 只做产量、产值等少量数据接口。

2.2 第一版明确不做

• 碳交易撮合、绿证交易、CCER 项目开发。
• 产品级碳足迹（LCA）全生命周期建模。
• 生产排程、设备预测性维护、EMS 需量控制闭环。
• 直接控制现场设备（除非有独立的安全联锁和变更管理）。

3. 用户角色

权限设计上，若依的角色 + 菜单权限 + 数据权限足够覆盖前五类。碳管理员和能源管理员通常是不同角色，因为碳核算涉及“数据锁定”和“因子版本”，不能让所有人改。

4. 功能架构

能碳管理系统
├── 驾驶舱
│   ├── 今日/本月能耗总览
│   ├── 能源成本与碳排总览
│   ├── 能流图（总表→分表）
│   ├── 趋势与排名
│   └── 报警与通信状态
├── 能源监控
│   ├── 实时数据（点位级）
│   ├── 设备/计量点状态
│   ├── 通信在线率
│   └── 历史曲线
├── 能耗分析
│   ├── 分项/分组织/分介质统计
│   ├── 同比环比
│   ├── 排名与占比
│   ├── 定额与考核
│   ├── 需量分析
│   └── 成本分析
├── 碳管理
│   ├── 排放源与核算边界
│   ├── 活动数据管理
│   ├── 排放因子库
│   ├── 核算任务与结果
│   ├── 碳强度
│   └── 核算报告
├── 报警与工单
│   ├── 报警规则
│   ├── 实时报警
│   ├── 报警确认/屏蔽
│   └── 工单流转
├── 基础数据
│   ├── 组织与班组
│   ├── 能源介质
│   ├── 计量点与点位
│   ├── 设备台账
│   ├── 班次与日历
│   └── 能源单价
└── 系统管理（若依自带）
    ├── 用户/角色/菜单/部门
    ├── 字典/参数/通知
    ├── 定时任务
    └── 日志/监控

4.1 驾驶舱

驾驶舱不是“把所有图表堆在一起”，而是回答管理层每天早上最关心的五个问题：

1. 今天到现在用了多少能、花了多少钱？
2. 和昨天/上月同期比，是升还是降？
3. 哪个车间/介质排第一？
4. 碳排放到多少了，离年度目标还有多远？
5. 有没有表断了、报警没处理？

技术上用 ECharts 的组合图：KPI 卡片 + 趋势折线 + 占比环图 + 排名条形图 + 能流桑基图。数据来自预聚合的日/月统计表，不要让驾驶舱直接查秒级原始数据。

4.2 能源监控

监控页的核心是“点位级可下钻”：

• 园区 → 车间 → 计量点 → 点位，四级下钻。
• 每个点位显示实时值、单位、采集时间、数据质量。
• 通信状态单独一栏：在线、离线、超时、数据异常。
• 历史曲线支持任意时间范围，超过 7 天自动降采样。

4.3 能耗分析

分析页的难点不是画图，而是口径。同一个“本月用电”，按自然月、抄表月、班次、生产日算出来可能都不一样。系统必须在页面上明确显示口径，并允许配置：

定额考核建议做成“基准值 + 调整系数”：基准值来自历史同期或工艺定额，调整系数考虑产量、天气、设备检修。不要用一条固定线卡死所有月份。

4.4 碳管理

碳管理不是“能耗乘以一个系数”这么简单，至少要拆成五步：

1. 定边界：组织边界（哪些法人/厂区）、运营边界（范围一/二/三）、时间边界（核算期间）。
2. 识别排放源：燃烧设备、外购电、外购蒸汽、制冷剂逸散、车辆、废弃物等。
3. 采集活动数据：电量、燃气量、蒸汽量、制冷剂补充量、产量/产值。
4. 选择排放因子：电网因子、燃料因子、蒸汽因子、GWP 值，全部带版本和来源。
5. 计算与报告：按范围汇总，出总排放、碳强度、同比、明细和凭证。

4.5 报警与工单

报警规则至少支持四类：

报警要能去重、抑制、升级：同一块表反复跳变，不能每分钟发一条短信；检修期间可以屏蔽；超过 30 分钟未确认自动升级给主管。

5. 核心业务流程

5.1 采集流程

仪表产生数据
   ↓（RS-485 / 4-20mA / 脉冲 / 以太网）
网关按周期轮询或主动上报
   ↓（本地缓存、越限判断、时间戳）
MQTT 发布到 EMQX
   ↓（QoS 1，断线重连）
采集服务订阅、解析、校验
   ↓
写时序库（原始值）+ 写 Redis（最新值）
   ↓
报警引擎判断 → 生成报警/工单
   ↓
定时任务聚合小时/日/月统计

关键原则：原始数据只写一次，统计结果可重算。原始数据是事实，统计口径可能变；口径变了要能重跑，而不是改历史。

5.2 能耗统计流程

1. 采集服务写入分钟级原始值。
2. 每小时聚合一次小时值：累计量取首尾差，瞬时量取平均/最大/最小。
3. 每天聚合日值，并处理跨零点、缺数、补数。
4. 每月生成月报，锁定后不允许直接改，只能走调整单。
5. 统计结果带上数据完整率：应采点数、实采点数、缺失点数。完整率低于阈值时，报表要标黄。

5.3 碳核算流程

选择核算期间与组织边界
   ↓
系统汇总活动数据（电、气、汽、制冷剂……）
   ↓
数据完整性检查（缺数、异常、单位）
   ↓
匹配排放因子（按介质、地区、年份、版本）
   ↓
按范围一/二/三计算
   ↓
生成核算结果与明细
   ↓
碳管理员复核 → 锁定 → 导出报告

6. 碳核算方法

这一节给出足够写代码的公式和口径。正式项目请以 GB/T 32150、ISO 14064-1、GHG Protocol 以及生态环境部发布的最新行业核算指南为准。

6.1 基本公式

排放量（tCO₂e）= Σ（活动数据 AD_i × 排放因子 EF_i × GWP_i）

• 活动数据 AD：用了多少能源或物料，单位要与因子匹配。
• 排放因子 EF：每单位活动数据的排放量。
• GWP：全球变暖潜势，CO₂ 取 1，CH₄ 取 28 或 29，N₂O 取 265 或 273（AR5/AR6 口径不同，必须固定并记录）。

6.2 范围划分

6.3 常用计算方式

外购电力（范围二）

排放量 = 外购电量（MWh）× 电网排放因子（tCO₂/MWh）

示例：120,000 kWh = 120 MWh，因子取 0.5568 tCO₂/MWh，则排放 66.816 tCO₂。

化石燃料燃烧（范围一）

排放量 = 消耗量 × 低位热值 × 单位热值含碳量 × 碳氧化率 × 44/12

很多指南会直接给出“每吨/每万立方米的排放因子”，系统里两种方式都要支持：直接因子和分项计算。

外购蒸汽/热（范围二）

排放量 = 蒸汽/热量（GJ）× 供汽排放因子（tCO₂/GJ）

制冷剂逸散（范围一）

排放量 = 补充量（kg）× GWP / 1000

6.4 一个完整的示例

假设某月：

• 范围一 = 17.472 + 4.176 = 21.648 tCO₂e
• 范围二 = 66.816 + 33.000 = 99.816 tCO₂e
• 合计 = 121.464 tCO₂e
• 若当月产值 500 万元，碳强度 = 121.464 / 500 = 0.243 tCO₂e/万元

6.5 组织边界与合并方式

系统里应把“组织边界”做成核算任务的一个属性，而不是写死在代码里。同一套数据，换一种合并方式，结果会不同。

7. 数据架构

7.1 分层

ODS  原始层：采集原始值、原始报文、质量码
DWD  明细层：清洗后的分钟/小时明细，统一单位与时区
DWS  汇总层：日、月、年，按组织/介质/计量点
ADS  应用层：驾驶舱、报表、碳核算结果

小项目不必上大数据平台，用“时序库 + MySQL 统计表”就能实现这四层。关键是每层职责清楚：

• ODS 只追加，不修改。
• DWD 做单位换算、异常标记、补数。
• DWS 可重算，保留计算版本。
• ADS 面向页面，允许冗余。

7.2 数据量估算

假设 1,000 个点位，每分钟采一次：

1,000 × 60 × 24 = 1,440,000 条/天
× 365 ≈ 5.26 亿条/年

这还没算报文和报警。MySQL 单表存这个量级会非常吃力，所以原始数据必须进时序库。时序库按列压缩后，一年通常只有几十 GB，具体取决于标签基数和压缩策略。

7.3 保留策略

8. 部署架构

8.1 推荐：单体应用 + 独立采集服务

                    ┌─────────────────────┐
   浏览器 ──HTTPS──▶│ Nginx               │
                    │ 静态资源 + 反向代理  │
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
                    │ RuoYi 应用（单体）    │
                    │ 业务 + 权限 + 报表    │
                    └───┬──────────┬──────┘
                        │          │
              ┌─────────▼──┐  ┌────▼─────────┐
              │ MySQL      │  │ Redis        │
              └────────────┘  └──────────────┘
                        │
              ┌─────────▼──────────┐
              │ TDengine           │
              └─────────▲──────────┘
                        │
              ┌─────────┴──────────┐      ┌──────────────┐
              │ Collector 服务      │◀────▶│ EMQX         │
              │ 协议适配 + 清洗      │ MQTT │ MQTT Broker  │
              └─────────▲──────────┘      └──────▲───────┘
                        │                        │
                        └──── 网关 / DTU ────────┘

为什么把采集服务独立出去：

• 协议库（Modbus、OPC UA、IEC 104）经常是阻塞 IO，和 Web 应用混在一起会拖慢页面。
• 采集服务需要独立重启、独立扩容、独立部署到靠近现场的网络区域。
• 采集服务权限更敏感，独立后可以只开放 MQTT 和时序库写权限，降低攻击面。

8.2 什么时候上微服务

9. 与若依模块的映射

业务模块建议单独建 Maven 模块，而不是全部塞进 ruoyi-system。这样采集、统计、碳核算的依赖不会污染系统模块，未来也更容易拆服务。

10. 非功能设计

11. 实施路线

实际项目里 P2 和 P3 会交叉：硬件到货晚，就先用 Modbus 模拟器开发；现场网络没通，就先用 MQTT 压测。不要等硬件全部到位才开始写软件。

12. 设计检查清单

在进入技术选型前，确认下面这些问题都有答案：

• 管哪些能源介质？每种介质的计量单位是什么？
• 组织层级几级？是否多园区、多法人？
• 总表、分表、设备表各多少个？是否需要总表-分表对账？
• 碳核算做到范围几？组织边界用哪种合并方式？
• 是否需要对接现有 PLC、DCS、MES、ERP？接口和责任人是谁？
• 现场有没有可用的网络？能否布线？谁负责施工？
• 报表口径按自然月还是抄表月？谁有权锁定数据？
• 数据保留几年？有没有等保、审计、国产化要求？

这些答案会直接决定下一章的选型。带着它们读技术栈会更有针对性。