去年 11 月在华东一个智慧园区的改造现场业主指着两套互不联网的后台问我们能不能在同一个屏幕上看到光伏发了多少、充电桩吃掉多少当时那个园区的配置是 1.2MW 分布式光伏加 40 台不同品牌的 120kW 直流快充桩。光伏数据在厂商云端充电桩则是接在第三方充电桩平台运营两个系统就像两条平行线。这种「光储充」场景在当下的工商业地产、物流园里非常普遍。但现实是大多数第三方充电桩平台运营数据与光伏监控是割裂的。作为架构师我们要解决的不仅是「把数据拉过来」更难的是多租户模式下的电费结算、动态扩容和能量流转的实时性问题。这篇文章想聊聊我们在架构这套系统时那些文档里没写、但能让你少走弯路的技术细节。### 协议的「大杂烩」从 OCPP 到厂商私有 API要做融合第一道关卡就是数据归一化。光伏侧大家很熟悉主流逆变器厂商华为、阳光、古瑞瓦特等通常提供 Cloud-to-Cloud API数据频率多在 5 分钟/次。但充电桩侧完全是另一套玩法。目前第三方充电桩平台运营通常基于 OCPP 1.6 或 2.0 协议或者干脆是厂商私有的 HTTP/MQTT 接口。充电桩的数据是「事件驱动」的插枪、鉴权、开始充电、功率波动、扣费、拔枪。如果你按光伏那种 5 分钟轮询一次的逻辑去接充电桩你的用户在手机端看到的充电进度条可能永远卡在 3 分钟前。我们在 2023 年底处理过一个 500 门桩的大型场站当时踩的一个坑是第三方平台的 API 限流极其严格。由于充电桩在充电过程中需要实时计算当前功率以配合光伏的「余电上网」策略我们最初尝试每 10 秒拉取一次数据结果上线不到 1 小时 IP 就被封禁了。最后的解决方案是光伏侧保持异步轮询充电侧改为 Webhook 推送订阅只有当电流波动超过 5A 或者状态变更时第三方平台才主动把数据「推」给我们。这种混合驱动架构让服务器 CPU 负载降低了 40% 左右。### 多租户管理的深水区谁在用我的绿电在光储充平台中「多租户」不是简单的权限隔离而是复杂的能源路由逻辑。一个园区里可能租给 A 公司、B 公司和 C 仓库每个租户都有自己的充电位。这时候业主最关心的是我这 10MW 光伏发的绿电到底有多少是被 A 公司的员工充掉的又有多少是卖给电网的这就涉及到一个关键字段的归一化tenant_id。我们在数据库设计时必须在底层的 telemetry 表之上构建一层逻辑资产映射Logic Asset Mapping。sql-- 典型的光储充数据关联逻辑SELECTt.tenant_name,SUM(p.pv_yield) as total_pv,SUM(c.charge_energy) as self_consumed_green_power,(SUM(c.charge_energy) / NULLIF(SUM(p.pv_yield), 0)) * 100 as green_ratioFROM tenant_assets taJOIN pv_data p ON ta.pv_inverter_id p.device_idJOIN charger_data c ON ta.charger_id c.device_idWHERE p.ts BETWEEN 2024-05-01 AND 2024-05-31GROUP BY t.tenant_id;实际操作中充电桩的 transaction_id充电订单号必须与光伏的 time_bucket时间桶对齐。我们通常以 1 分钟为最小颗粒度做聚合。如果 A 租户在 10:00 到 10:30 充电我们需要抓取这 30 分钟内对应光伏阵列的平均出力通过加权算法计算出他的「绿电占比」。这种数据颗粒度才是真正能拿给租户看、甚至做碳减排抵消的依据。### 逻辑避雷充电桩运营平台哪个好用很多同行会问市面上这么多第三方充电桩平台运营到底哪个好接实话说没有最好的只有最合适的。我们在选型时主要看三个指标1. **API 的完整度**有些平台只能看充电度数看不了实时电压、电流和功率这对于要做「光储充联动」或者「有序充电」的平台来说是致命的。如果拿不到实时功率你的 EMS 策略就是瞎子点灯。2. **延时水平**从桩端心跳到 API 接口更新延时是否在 3-5 秒区间内。超过 10 秒的延时用户体验会非常糟糕。3. **错误码透明度**当充电桩因为「接地故障」或「急停按下」断开时平台能否返回具体的原始错误码。很多平台会粗暴地归类为「设备离线」这给后期运维增加了巨大的成本。### 架构的「减法」为什么不自己接所有 API在做了 30 多个项目后我们发现一个痛点维护成本是指数级增长的。今天华为的 API 升级了明天阳光电源的字段改名了后天某个充电桩品牌被收购了接口全变了。如果你在业务层直接写这些适配逻辑你的后端工程师很快就会陷入「改 Bug 地狱」。我们团队目前的做法是把这层接入全面抽离。说白了就是建立一个专门的数据接入中间件把不同协议、不同厂商的 API 统一成一套标准的 JSON 格式。比如不管它是 Modbus 里的 0x0031 寄存器还是云端 API 里的 active_power推给上层平台的永远是标准的 p_active。在这个领域我们打磨出的 ZenovaConnect 就是专门干这个苦力活的它屏蔽了 30 多家主流逆变器和充电桩品牌的协议差异让上层平台只需要关心业务逻辑和多租户 UI。### 结语与取舍光储充一体化的核心不在于「桩」或「板」本身而在于数据的流转效率。在架构设计上我们倾向于「重网关、轻业务」的策略即在接入层解决掉 90% 的兼容性问题。如果你正在面对几十个场站、上百种设备接入千万不要试图用一套 if-else 走天下。一个值得思考的问题在你的光储充项目中最让你头疼的是数据不准还是跨平台的账号体系打不通欢迎在后台分享你的踩坑经历。
300个充电桩和10MW光伏：打通多租户光储充平台的架构实战
去年 11 月在华东一个智慧园区的改造现场业主指着两套互不联网的后台问我们能不能在同一个屏幕上看到光伏发了多少、充电桩吃掉多少当时那个园区的配置是 1.2MW 分布式光伏加 40 台不同品牌的 120kW 直流快充桩。光伏数据在厂商云端充电桩则是接在第三方充电桩平台运营两个系统就像两条平行线。这种「光储充」场景在当下的工商业地产、物流园里非常普遍。但现实是大多数第三方充电桩平台运营数据与光伏监控是割裂的。作为架构师我们要解决的不仅是「把数据拉过来」更难的是多租户模式下的电费结算、动态扩容和能量流转的实时性问题。这篇文章想聊聊我们在架构这套系统时那些文档里没写、但能让你少走弯路的技术细节。### 协议的「大杂烩」从 OCPP 到厂商私有 API要做融合第一道关卡就是数据归一化。光伏侧大家很熟悉主流逆变器厂商华为、阳光、古瑞瓦特等通常提供 Cloud-to-Cloud API数据频率多在 5 分钟/次。但充电桩侧完全是另一套玩法。目前第三方充电桩平台运营通常基于 OCPP 1.6 或 2.0 协议或者干脆是厂商私有的 HTTP/MQTT 接口。充电桩的数据是「事件驱动」的插枪、鉴权、开始充电、功率波动、扣费、拔枪。如果你按光伏那种 5 分钟轮询一次的逻辑去接充电桩你的用户在手机端看到的充电进度条可能永远卡在 3 分钟前。我们在 2023 年底处理过一个 500 门桩的大型场站当时踩的一个坑是第三方平台的 API 限流极其严格。由于充电桩在充电过程中需要实时计算当前功率以配合光伏的「余电上网」策略我们最初尝试每 10 秒拉取一次数据结果上线不到 1 小时 IP 就被封禁了。最后的解决方案是光伏侧保持异步轮询充电侧改为 Webhook 推送订阅只有当电流波动超过 5A 或者状态变更时第三方平台才主动把数据「推」给我们。这种混合驱动架构让服务器 CPU 负载降低了 40% 左右。### 多租户管理的深水区谁在用我的绿电在光储充平台中「多租户」不是简单的权限隔离而是复杂的能源路由逻辑。一个园区里可能租给 A 公司、B 公司和 C 仓库每个租户都有自己的充电位。这时候业主最关心的是我这 10MW 光伏发的绿电到底有多少是被 A 公司的员工充掉的又有多少是卖给电网的这就涉及到一个关键字段的归一化tenant_id。我们在数据库设计时必须在底层的 telemetry 表之上构建一层逻辑资产映射Logic Asset Mapping。sql-- 典型的光储充数据关联逻辑SELECTt.tenant_name,SUM(p.pv_yield) as total_pv,SUM(c.charge_energy) as self_consumed_green_power,(SUM(c.charge_energy) / NULLIF(SUM(p.pv_yield), 0)) * 100 as green_ratioFROM tenant_assets taJOIN pv_data p ON ta.pv_inverter_id p.device_idJOIN charger_data c ON ta.charger_id c.device_idWHERE p.ts BETWEEN 2024-05-01 AND 2024-05-31GROUP BY t.tenant_id;实际操作中充电桩的 transaction_id充电订单号必须与光伏的 time_bucket时间桶对齐。我们通常以 1 分钟为最小颗粒度做聚合。如果 A 租户在 10:00 到 10:30 充电我们需要抓取这 30 分钟内对应光伏阵列的平均出力通过加权算法计算出他的「绿电占比」。这种数据颗粒度才是真正能拿给租户看、甚至做碳减排抵消的依据。### 逻辑避雷充电桩运营平台哪个好用很多同行会问市面上这么多第三方充电桩平台运营到底哪个好接实话说没有最好的只有最合适的。我们在选型时主要看三个指标1. **API 的完整度**有些平台只能看充电度数看不了实时电压、电流和功率这对于要做「光储充联动」或者「有序充电」的平台来说是致命的。如果拿不到实时功率你的 EMS 策略就是瞎子点灯。2. **延时水平**从桩端心跳到 API 接口更新延时是否在 3-5 秒区间内。超过 10 秒的延时用户体验会非常糟糕。3. **错误码透明度**当充电桩因为「接地故障」或「急停按下」断开时平台能否返回具体的原始错误码。很多平台会粗暴地归类为「设备离线」这给后期运维增加了巨大的成本。### 架构的「减法」为什么不自己接所有 API在做了 30 多个项目后我们发现一个痛点维护成本是指数级增长的。今天华为的 API 升级了明天阳光电源的字段改名了后天某个充电桩品牌被收购了接口全变了。如果你在业务层直接写这些适配逻辑你的后端工程师很快就会陷入「改 Bug 地狱」。我们团队目前的做法是把这层接入全面抽离。说白了就是建立一个专门的数据接入中间件把不同协议、不同厂商的 API 统一成一套标准的 JSON 格式。比如不管它是 Modbus 里的 0x0031 寄存器还是云端 API 里的 active_power推给上层平台的永远是标准的 p_active。在这个领域我们打磨出的 ZenovaConnect 就是专门干这个苦力活的它屏蔽了 30 多家主流逆变器和充电桩品牌的协议差异让上层平台只需要关心业务逻辑和多租户 UI。### 结语与取舍光储充一体化的核心不在于「桩」或「板」本身而在于数据的流转效率。在架构设计上我们倾向于「重网关、轻业务」的策略即在接入层解决掉 90% 的兼容性问题。如果你正在面对几十个场站、上百种设备接入千万不要试图用一套 if-else 走天下。一个值得思考的问题在你的光储充项目中最让你头疼的是数据不准还是跨平台的账号体系打不通欢迎在后台分享你的踩坑经历。
