通用公用事业云平台架构设计：兼容燃气、水务与电力的一体化计量运营平台

1. 为什么需要一体化公用事业云平台

燃气、水务、电力、热力看起来是不同业务，但从企业运营和系统建设视角看，它们存在大量共性：

• 都有客户。
• 都有合同或户号。
• 都有服务地址。
• 都有计量点。
• 都有表计或终端设备。
• 都有远程采集。
• 都有用量计算。
• 都有计费出账。
• 都有缴费核销。
• 都有欠费控制。
• 都有设备异常。
• 都有现场工单。
• 都有报表统计。
• 都有第三方集成。

如果每个能源类型都建设一套完全独立的系统，会带来明显问题：

• 重复建设客户、权限、账务、支付、报表。
• 多套设备接入链路重复开发。
• 客户化交付成本高。
• 数据口径不统一。
• 运维监控割裂。
• 后续扩展新能源类型困难。

因此，更合理的方向是：

统一平台底座 + 能源类型扩展 + 协议插件 + 业务规则插件

燃气、水务、电力不是三套系统，而是同一套公用事业平台上的不同能源业务域。

2. 平台总体定位

通用公用事业云平台可以定位为：

面向燃气、水务、电力、热力等公用事业企业的多租户计量运营云平台。

它覆盖从物理设备到经营收费的完整链路：

资产建档 -> 装表绑定 -> 设备接入 -> 数据采集 -> 数据清洗 -> 计费出账 -> 支付核销 -> 命令控制 -> 告警诊断 -> 工单处理 -> 报表分析 -> 运维监控

平台不是单一 HES，也不是单一 CIS，而是把设备侧、数据侧、业务侧、账务侧和运维侧统一起来。

3. 企业级系统分层

一个完整的公用事业 IT 架构，通常可以拆成几类核心系统。

3.1 资产系统

资产系统负责管理真实世界中的设备。

包括：

• 表计采购。
• 入库。
• 领用。
• 安装。
• 运行。
• 拆回。
• 维修。
• 报废。
• 设备密钥。
• 通信参数。
• 表计与户号绑定关系。

它是设备的“户口本”。

资产系统关心的是：

这块表是谁的、在哪里、什么型号、什么状态、绑定哪个计量点。

3.2 WFM 工单系统

WFM 是现场人员调度系统。

它负责连接线上系统和线下作业：

• 安装工单。
• 换表工单。
• 报修工单。
• 巡检工单。
• 安检工单。
• 催缴工单。
• 异常处理工单。
• 现场拍照。
• 现场回填。
• 工单回访。

它是现场运维的“调度中心”。

3.3 HES 采集前置系统

HES 面向硬件，负责设备通信。

职责：

• 协议编解码。
• 加密解密。
• 报文校验。
• 设备上报接收。
• 命令下发。
• 硬件级状态监控。
• 通信通道管理。

HES 应尽量保持“瘦”和“无状态”。

它不应该理解复杂账务，不应该直接处理客户合同，不应该参与计费逻辑。

HES 关心的是：

设备是否连得上、数据是否收得到、命令是否下得去。

3.4 MDM 表计数据管理系统

MDM 是计量数据管理中心。

职责：

• 标准读数管理。
• 冻结数据管理。
• VEE 数据处理。
• 设备事件。
• 业务级告警。
• 命令状态机。
• 数据质量分析。

VEE 指：

Validation 验证 Estimation 估算 Editing 编辑

例如：

• 剔除异常负数读数。
• 识别突增突减。
• 对缺失数据估算。
• 对异常数据人工修正。

MDM 是设备数据到业务数据之间的“质检员”。

3.5 CIS 客户与计费系统

CIS 是客户和计费系统。

职责：

• 客户。
• 合同/户号。
• 服务地址。
• 计量点。
• 价格方案。
• 账单。
• 缴费。
• 退款。
• 对账。
• 票据。

CIS 是商业闭环的核心。

它关心的是：

谁用了多少、该收多少钱、是否已经缴费。

3.6 开放集成系统

开放集成系统负责对接外部生态：

• 银行。
• 支付渠道。
• 监管平台。
• 营业系统。
• 厂商平台。
• 短信平台。
• 发票平台。
• 第三方 APP。

它需要提供：

• API 鉴权。
• 签名验签。
• 报文转换。
• 接口审计。
• 重试补偿。
• 错误码映射。

4. 总体微服务架构

平台微服务架构可以设计为：

Web 管理端 / 移动端 / 第三方系统 / 银行 / 支付 / 监管 | API 网关 | 认证权限服务 | 业务微服务层 | 消息队列 / Redis / 数据库 / 文件服务 / 调度平台 / 日志监控 | HES / 前置机 / 网关 / 表计 / 厂商平台

核心微服务：

iam-service 认证权限服务 tenant-org-service 租户组织服务 customer-contract-service 客户合同服务 measuring-point-service 计量点服务 asset-service 设备资产服务 hes-gateway-service 设备接入网关 protocol-adapter-service 协议适配服务 mdm-service 表计数据管理服务 command-service 命令控制服务 billing-service 计费账务服务 payment-service 支付对账服务 alarm-service 告警诊断服务 work-order-service 工单运维服务 report-service 报表分析服务 integration-service 开放集成服务 notification-service 消息通知服务 scheduler-service 调度任务服务 file-service 文件服务

服务拆分不是为了数量多，而是为了边界清楚。

5. 统一业务域设计

建议将平台统一为以下业务域：

6. 统一核心模型

一体化平台最关键的是统一模型。

6.1 能源类型

统一使用：

utility_type

可选值：

GAS 燃气 WATER 水务 ELECTRIC 电力 HEAT 热力

所有核心对象都应能感知能源类型：

• 计量点。
• 表计设备。
• 读数。
• 用量。
• 价格方案。
• 账单。
• 命令。
• 告警。
• 报表。

6.2 客户与合同

Customer 客户 Contract 合同/户号 ServiceAddress 服务地址

客户是自然人或企业。

合同/户号是客户与公用事业公司的服务关系。

一个客户可以有多个合同，一个合同可以有一个或多个计量点。

6.3 计量点

计量点是平台最重要的业务锚点。

Customer -> Contract -> ServiceAddress -> MeasuringPoint -> Device

计量点绑定：

• 能源类型。
• 价格方案。
• 账户。
• 抄表周期。
• 计费方式。
• 控制策略。
• 当前设备。

换表时，计量点不变，只变更设备绑定关系。

6.4 设备

统一设备模型：

Device MeterDevice GatewayDevice DeviceRelation DeviceParameter DeviceKey DeviceLifecycle

设备类型：

GAS_METER WATER_METER ELECTRIC_METER HEAT_METER RTU GATEWAY CONCENTRATOR REPEATER SIM SENSOR

6.5 读数与用量

统一读数模型：

MeterReading FrozenReading UsageQuantity ReadingValidation ReadingVersion

字段抽象：

reading_value 表码 usage_quantity 本期用量 reading_time 读数时间 reading_type 读数类型 utility_type 能源类型 quality_flag 数据质量标记

读数类型：

REALTIME DAILY_FROZEN MONTHLY_FROZEN MANUAL ESTIMATED BILLING

6.6 命令

统一命令模型：

CommandTask CommandTarget CommandPayload CommandDispatchLog CommandResult CommandRetry CommandAudit

不同能源命令能力：

6.7 账务

统一账务模型：

Account AccountLedger Bill BillDetail Receivable PaymentOrder ChannelOrder RefundOrder ReconciliationBatch ReconciliationDetail

账务核心必须独立，不应散落在设备协议、支付回调或命令控制服务中。

7. 能源差异设计

7.1 燃气

燃气重点：

• 安全阀控。
• 欠费关阀。
• IC/STS。
• 远程充值。
• 补气、退气。
• 安检。
• 异常用气。
• 工商表。
• RTU。
• 压力温度修正。

典型异常：

• 磁攻击。
• 低电压。
• 欠费关阀。
• 阀门异常。
• 异常用气。
• 长时间未上报。

7.2 水务

水务重点：

• 远程抄表。
• 漏水。
• 滴漏。
• 倒流。
• 空管。
• DMA 分区。
• 产销差。
• 污水处理费。
• 垃圾费。

典型异常：

• 持续流。
• 小流量泄漏。
• 大流量泄漏。
• 反向计量。
• 开盖。
• 阀门异常。
• 长时间未上报。

7.3 电力

电力扩展时需要重点考虑：

• 电能表示数。
• 分时电价。
• 尖峰平谷。
• 需量。
• 功率因数。
• 拉合闸。
• 费控。
• 线损。
• 台区。
• 变压器。

典型异常：

• 失压。
• 失流。
• 反向电量。
• 开盖。
• 窃电疑似。
• 功率异常。
• 负荷异常。
• 通讯异常。

电力和燃气、水务最大的差异是：

计量指标更多，价格规则更复杂，电网拓扑更强，数据采集频率更高。

因此平台模型要给电力预留扩展字段和扩展表，而不是把所有电力指标硬塞进通用读数字段。

8. 插件化设计

一体化平台要避免所有差异都写进核心代码。

建议插件化的能力：

8.1 能源插件

GasUtilityPlugin WaterUtilityPlugin ElectricUtilityPlugin HeatUtilityPlugin

负责定义：

• 能源类型。
• 计量单位。
• 费用项。
• 命令能力。
• 典型异常。
• 报表指标。

8.2 协议插件

负责：

• 报文解析。
• 命令组包。
• 回执解析。
• 数据项映射。

协议插件不直接处理账务和客户。

8.3 计费插件

负责：

• 阶梯价。
• 分时价。
• 包量价。
• 污水费。
• 滞纳金。
• 附加费。
• 优惠减免。

8.4 诊断规则插件

负责：

• 漏水诊断。
• 异常用气诊断。
• 窃电疑似诊断。
• 通讯异常诊断。
• 设备故障诊断。

8.5 客户化适配插件

负责：

• 银行接口。
• 支付渠道。
• 监管平台。
• 厂商平台。
• 地方营业系统。

客户化能力必须隔离在 adapter 层，不进入核心域。

9. HES 与 MDM 的边界

9.1 HES 应该做什么

HES 负责：

• 接收设备报文。
• 协议解码。
• 加密解密。
• 命令组包。
• 通道管理。
• 硬件级异常。

HES 不应该做：

• 客户账务。
• 价格计算。
• 账单核销。
• 复杂业务规则。
• 报表统计。

9.2 MDM 应该做什么

MDM 负责：

• 标准读数。
• 冻结读数。
• 数据质量。
• VEE。
• 业务级告警。
• 命令状态机。
• 读数发布。

MDM 是 HES 和 CIS 之间的数据中枢。

9.3 采用“瘦 HES，胖 MDM”

推荐原则：

HES 轻状态，MDM 管数据质量和业务状态。

这样 HES 可以横向扩容，MDM 保持业务一致性。

10. 休眠设备下的命令控制设计

很多智能水表、燃气表、电表终端都不是一直在线。

例如：

• NB-IoT PSM。
• LoRa Class A。
• 低功耗远传表。

这类设备长期休眠，只有上报时才短暂打开接收窗口。

如果按传统同步调用方式下发命令，很容易失败。

推荐使用：

Redis 下发共享池 + Kafka 结果回执流

10.1 下行链路

CIS/业务服务发起命令 -> MDM 创建命令记录 -> 生成 TraceID -> 命令写入 Redis -> 设置 TTL

10.2 设备唤醒

设备周期上报 -> HES 接收报文 -> HES 查询 Redis 是否有待下发命令 -> 命中则在 ACK 窗口下发 -> 删除或标记 Redis 命令

10.3 回执链路

设备执行命令 -> HES 解析回执 -> 写入 Kafka Result Topic -> MDM 消费结果 -> 更新命令状态 -> 触发业务补偿

这种设计的好处：

• HES 不需要保存复杂业务状态。
• MDM 保持命令一致性。
• Redis 适合作为待下发命令池。
• Kafka 适合作为结果事件流。
• 适配低功耗设备的唤醒窗口。

11. 核心业务流程

11.1 开户装表

创建客户 -> 创建合同/户号 -> 创建服务地址 -> 创建计量点 -> 选择能源类型 -> 绑定设备 -> 绑定价格方案 -> 创建账户 -> 设备开通 -> 写审计日志

11.2 采集入库

设备上报 -> HES 接收 -> 原始报文落库 -> 协议解析 -> 标准读数 -> MDM 数据校验 -> 读数发布 -> 计费/告警/报表消费

11.3 计费出账

标准读数 -> 计算用量 -> 匹配价格方案 -> 计算费用 -> 生成账单 -> 预付费扣款或后付费待缴 -> 写账户流水

11.4 支付核销

客户支付 -> 创建支付订单 -> 渠道回调 -> 幂等校验 -> 写收款记录 -> 核销账单 -> 更新账户 -> 参与对账

11.5 欠费控制

账单逾期 -> 欠费策略判断 -> 生成催缴通知 -> 必要时创建控制命令 -> MDM 登记命令状态 -> HES 下发 -> 回执后更新业务状态

11.6 异常工单

设备事件/数据异常 -> 诊断规则匹配 -> 生成告警 -> 自动建工单 -> 派发现场人员 -> 现场处理 -> 回填结果 -> 关闭工单

12. 数据架构设计

12.1 主数据层

tenant organization region customer contract service_address measuring_point device price_plan account

12.2 采集时序层

raw_message parse_result meter_reading frozen_reading device_event reading_validation reading_version

12.3 命令控制层

command_task command_target command_payload command_dispatch_log command_result command_retry command_audit

12.4 账务支付层

bill bill_detail account_ledger payment_order channel_order refund_order reconciliation_batch reconciliation_detail

12.5 告警工单层

alarm_event diagnostic_rule diagnostic_case work_order work_order_action notice

12.6 汇总分析层

stat_daily_usage stat_monthly_usage stat_payment stat_arrearage stat_device_online stat_alarm stat_command_success

13. 安全与权限设计

平台必须具备：

• 多租户隔离。
• 组织数据权限。
• 区域数据权限。
• 菜单权限。
• 按钮权限。
• API 权限。
• 敏感数据脱敏。
• 操作审计。
• 接口签名。
• 防重放。
• IP 白名单。

重点审计操作：

• 远程关阀。
• 电力拉闸。
• 批量控制。
• 退款。
• 冲正。
• 调价。
• 密钥更新。
• 数据导出。

14. 报表与数仓设计

报表不建议直接查业务大表。

建议采用：

业务明细 -> 指标汇总 -> 报表展示

报表类型：

• 用量报表。
• 收费报表。
• 欠费报表。
• 抄表成功率。
• 设备在线率。
• 告警统计。
• 工单统计。
• 对账报表。
• 经营看板。

指标口径需要版本化。

例如：

• 水务产销差率。
• 燃气异常用气率。
• 电力线损率。
• 命令成功率。
• 设备在线率。
• 账单回收率。

15. 产品化落地路线

阶段一：统一主模型

• 租户。
• 组织。
• 区域。
• 客户。
• 合同。
• 地址。
• 计量点。
• 设备。
• 价格。
• 账户。

阶段二：水务闭环

• 水表资产。
• 远程抄表。
• 水费计费。
• 缴费。
• 漏水诊断。
• 工单。
• 产销差。

阶段三：燃气闭环

• 燃气表。
• 远程充值。
• 阀控。
• IC/STS。
• 安检。
• 异常用气。
• 燃气报表。

阶段四：电力扩展

• 电能表。
• 分时电价。
• 拉合闸。
• 线损。
• 台区。
• 负荷分析。
• 电力异常。

阶段五：统一设备接入

• HES。
• 协议插件。
• 通道适配。
• 原始报文。
• 命令回执。
• 设备在线。

阶段六：平台化交付

• 多租户。
• 客户化适配。
• 开放 API。
• 监管接口。
• 报表数仓。
• 运维监控。

16. 总结

通用公用事业云平台的目标，不是把燃气、水务、电力系统简单合并，而是抽象出一套稳定的业务内核：

客户 -> 合同 -> 计量点 -> 设备 -> 读数 -> 用量 -> 账单 -> 支付 -> 报表

再围绕这个内核扩展：

协议插件 能源插件 计费插件 诊断插件 客户化适配插件

燃气、水务、电力的差异应体现在插件和规则中，而不是让核心模型分裂成三套。

面向长期产品化，最重要的几个原则是：

• 计量点作为业务锚点。
• HES 保持轻状态。
• MDM 负责数据质量和命令状态。
• CIS 负责客户与计费。
• 账务核心独立。
• 协议适配插件化。
• 客户化接口隔离。
• 报表走汇总层。

一句话总结：

一体化平台的价值，不是支持多少种能源，而是用一套稳定模型承载多种能源的差异。