---
title: "总体设计"
description: "先定边界再写代码：能碳系统的业务范围、角色、功能架构、数据流、碳核算方法和部署架构。"
---

> Documentation Index
> Fetch the complete documentation index at: https://sdoc.mayekun.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 总体设计

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

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

## 1. 建设目标

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

| 诉求 | 具体表现 | 系统能力 |
| --- | --- | --- |
| 看得见 | 现在用了多少电、哪条线在跑、哪块表断了 | 实时采集、能流图、设备状态、通信状态 |
| 算得清 | 昨天/上月/本季度用了多少、花了多少钱、谁用得多 | 分项统计、同比环比、排名、定额考核、成本核算 |
| 管得住 | 超限报警、需量越限、异常用能、跑冒滴漏 | 报警规则、工单、需量预测、异常检测 |
| 报得出 | 碳排放多少、范围一/二各多少、碳强度多少 | 碳核算、因子库、核算报告、数据溯源 |

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

## 2. 业务边界

### 2.1 建议纳入第一版的范围

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

### 2.2 第一版明确不做

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

> **边界要写进合同或需求文档**
>
> “能碳系统”在不同人嘴里含义完全不同。把上面两张表放到需求文档首页，让甲方或老板签字确认。后面每加一个介质、一级组织、一类报告，都按变更流程走。

## 3. 用户角色

| 角色 | 关心什么 | 典型操作 |
| --- | --- | --- |
| 能源管理员 | 今天用了多少、哪块表异常、有没有超定额 | 看驾驶舱、处理报警、导出报表、维护计量点 |
| 车间 / 产线负责人 | 本车间能耗、同比环比、班组排名 | 看本组织数据、确认异常、填报产量 |
| 碳管理员 | 活动数据是否完整、因子是否正确、核算结果 | 发起核算、选择因子、锁定数据、生成报告 |
| 管理层 | 总能耗、总成本、碳强度、趋势 | 看驾驶舱、看月报、看排名 |
| 运维人员 | 网关在线率、仪表故障、数据质量 | 看通信状态、派工单、维护设备台账 |
| 系统管理员 | 用户、角色、菜单、字典、参数 | 若依系统管理 |

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

## 4. 功能架构

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

### 4.1 驾驶舱

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

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

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

### 4.2 能源监控

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

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

### 4.3 能耗分析

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

| 口径 | 说明 | 适用 |
| --- | --- | --- |
| 自然月 | 每月 1 日 00:00 到月末 23:59 | 对外报表、碳核算 |
| 抄表月 | 按电费单的抄表起止日 | 与电费对账 |
| 生产日 | 例如 08:00 到次日 08:00 | 班组考核 |
| 班次 | 早/中/晚班 | 车间考核 |

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

### 4.4 碳管理

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

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

### 4.5 报警与工单

报警规则至少支持四类：

| 类型 | 例子 | 判定方式 |
| --- | --- | --- |
| 阈值报警 | 有功功率超过 800 kW | 点位值 + 比较符 + 持续时间 |
| 变化率报警 | 10 分钟内电量突增 50% | 滑动窗口斜率 |
| 通信报警 | 连续 3 个周期没收到数据 | 采集心跳/超时 |
| 业务报警 | 车间月能耗超定额 10% | 统计结果 + 规则 |

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

## 5. 核心业务流程

### 5.1 采集流程

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

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

### 5.2 能耗统计流程

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

### 5.3 碳核算流程

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

## 6. 碳核算方法

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

### 6.1 基本公式

```text
排放量（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 常用计算方式

**外购电力（范围二）**

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

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

**化石燃料燃烧（范围一）**

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

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

**外购蒸汽/热（范围二）**

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

**制冷剂逸散（范围一）**

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

### 6.4 一个完整的示例

假设某月：

| 排放源 | 活动数据 | 因子（示例） | 排放量 |
| --- | --- | --- | --- |
| 外购电 | 120,000 kWh | 0.5568 tCO₂/MWh | 66.816 tCO₂ |
| 天然气 | 8,000 Nm³ | 21.84 tCO₂/万 Nm³ | 17.472 tCO₂ |
| 外购蒸汽 | 300 GJ | 0.11 tCO₂/GJ | 33.000 tCO₂ |
| 制冷剂 R410A | 2 kg | GWP 2088 | 4.176 tCO₂e |

- 范围一 = 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 组织边界与合并方式

| 方式 | 规则 | 适用 |
| --- | --- | --- |
| 运营控制权法 | 对拥有运营控制权的设施 100% 计入 | 大多数企业首选 |
| 财务控制权法 | 对财务控制的设施 100% 计入 | 与财务合并报表一致 |
| 股权比例法 | 按持股比例计入 | 合资、参股较多时 |

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

## 7. 数据架构

### 7.1 分层

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

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

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

### 7.2 数据量估算

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

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

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

### 7.3 保留策略

| 数据 | 保留 | 说明 |
| --- | --- | --- |
| 秒/分钟原始值 | 1～3 年 | 碳核查通常要看历史，建议至少 3 年 |
| 小时值 | 5～10 年 | 报表和趋势分析 |
| 日/月值 | 长期 | 归档到 MySQL 或对象存储 |
| 报警/操作日志 | 3 年 | 审计要求 |
| 核算报告与因子版本 | 长期 | 碳报告的可追溯性 |

## 8. 部署架构

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

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

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

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

### 8.2 什么时候上微服务

| 条件 | 建议 |
| --- | --- |
| 1 个园区、1 个团队、点位少于 5,000 | 单体 + 独立采集，足够 |
| 多园区、多租户、多个团队并行开发 | RuoYi-Cloud 微服务 |
| 需要独立扩容采集/报表/碳核算 | 至少把采集和报表拆出去 |
| 客户强制要求信创或国产中间件 | 单独评估，不要为了微服务而微服务 |

## 9. 与若依模块的映射

| 若依模块 | 在本系统中的职责 | 是否改造 |
| --- | --- | --- |
| `ruoyi-admin` | Web 入口、业务 Controller、启动类 | 增加业务包 |
| `ruoyi-framework` | Spring Security、JWT、数据源、拦截器 | 少量扩展 |
| `ruoyi-system` | 用户、角色、菜单、部门、字典、参数 | 基本复用 |
| `ruoyi-common` | 工具类、注解、统一返回、异常 | 增加能源/碳相关工具 |
| `ruoyi-quartz` | 定时聚合、报表生成、核算任务 | 复用 |
| `ruoyi-generator` | 单表 CRUD 代码生成 | 复用，生成后手工改 |
| **新增 `ruoyi-energy`** | 计量点、采集、统计、报警、碳核算 | 新建业务模块 |
| **新增 `collector`** | 协议适配、MQTT 接入、数据清洗 | 独立 Spring Boot 服务 |

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

## 10. 非功能设计

| 维度 | 目标 | 做法 |
| --- | --- | --- |
| 性能 | 页面接口 P95 小于 500ms，驾驶舱小于 3s | 预聚合、Redis 缓存、时序库降采样 |
| 采集能力 | 单采集服务 5,000 点位，1 分钟周期 | 连接池、批量写、异步队列 |
| 可用性 | 采集服务断线自动重连，网关离线缓存 7 天 | MQTT QoS 1、本地缓存、补传 |
| 数据质量 | 通信在线率 ≥ 98%，电量与电费单偏差 ≤ 1% | 心跳、质量码、对账报表 |
| 安全 | OT/IT 隔离，最小权限，全量审计 | 防火墙、VLAN、角色权限、操作日志 |
| 可扩展 | 新增介质/协议不改核心表 | 介质字典、协议适配器、点位模板 |
| 可运维 | 5 分钟内定位是仪表、网关还是平台问题 | 分层健康检查、链路追踪、告警 |

## 11. 实施路线

| 阶段 | 周期（参考） | 交付物 | 验收标准 |
| --- | --- | --- | --- |
| P0 调研 | 1～2 周 | 计量点清单、点位表、网络图 | 甲方确认点位和边界 |
| P1 底座 | 1～2 周 | 若依工程、数据库、权限、菜单 | 登录、组织、角色可用 |
| P2 采集 | 2～3 周 | 网关配置、采集服务、时序库 | 一条介质的数据稳定入库 |
| P3 业务 | 3～4 周 | 监控、统计、报警、报表 | 总表与分表对账通过 |
| P4 碳核算 | 2～3 周 | 因子库、核算任务、报告 | 与手工 Excel 核算一致 |
| P5 上线 | 1～2 周 | 部署、培训、验收文档 | 连续 7 天稳定运行 |

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

## 12. 设计检查清单

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

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

这些答案会直接决定下一章的选型。带着它们读[技术栈](/nengtan/tech-stack/)会更有针对性。

Source: https://sdoc.mayekun.com/nengtan/architecture/index.mdx