协议包怎么卖：按厂商打包，还是按协议打包？

做工业边缘软件商业化的同行，常会遇到一个具体问题：协议适配能力（Protocol Pack）作为可选模块售卖时，颗粒度怎么选——按厂商打包（华为包 / 阳光包 / 锦浪包），还是按协议打包（Modbus 包 / IEC 104 包 / SunSpec 包）？

表面上是商业决策，背后其实是技术架构 + 客户需求模型的选择。这篇写给集成商、商务负责人和设备制造商，讲清两种思路的权衡。

一、两种颗粒度的本质差异

按厂商打包

卖法：「华为逆变器接入包」「阳光电源接入包」「锦浪逆变器接入包」——每包覆盖该厂商的多种型号和多种协议。

好处：

• 客户视角直观：我有华为逆变器 → 买华为包
• 商务沟通容易：按厂家清单就能对定价单
• OEM 合作清晰：跟厂家直接谈「这家的接入包」

坏处：

• 与技术架构不对齐：一个 Modbus 实现服务多家厂商，按厂家打包等于重复计价
• 边界模糊：同一厂商不同产品线（华为光伏 / 华为储能 / 华为充电桩）算一个包还是三个？
• 长尾厂商难包装：小厂商客户少，单独成包不划算，塞进通用包又显得不公平

按协议打包

卖法：「Modbus 协议包」「IEC 104 协议包」「SunSpec 协议包」——每包覆盖该协议下的任意厂商、任意设备。

好处：

• 与技术架构对齐：协议运行时的内部分层就是按协议组织的
• 抽象层级清晰：客户买的是「能力」，不是「跟某家的关系」
• 长尾覆盖好：买了 Modbus 包就能跑任何符合规约的设备（配合点表）

坏处：

• 客户难理解：「我买的是设备 A，为什么还要懂协议？」
• 销售周期长：商务对话要先解释协议层级
• 定价复杂：协议有大有小（Modbus 使用面广、SunSpec 相对窄），差异化定价难说清

两种颗粒度对照：

二、混合颗粒度（实战推荐）

纯一种颗粒度都不理想，实战建议混合：

层 1：基础协议包（多数客户必选）

• Modbus RTU/TCP——覆盖大多数现场接入需求
• 电力行业规约：DL/T 645（多功能电能表通信协议）、DL/T 698.45（面向对象的数据交换协议）

这层按协议打包：跨厂商共用，按厂家拆分没有意义。

层 2：行业协议包（特定项目需要）

• IEC 60870-5-104（调度接入，简称 IEC 104）
• IEC 61850（变电站自动化）
• SunSpec（出海项目）

按协议打包：单独使用、需求明确。

层 3：厂商专项包（处理 quirks）

• 华为 FusionSolar（Northbound OpenAPI）
• 阳光 iSolarCloud Open API
• 锦浪 SolisCloud API

这层按厂商打包：云平台 API 本身厂家专属，工程量也专属。

客户沿着「我有这些设备 → 需要哪些能力 → 买哪些包」的路径决策，会更清晰。

三、定价设计

基础协议包：标配

建议基础 License 直接包含 Modbus + DL/T 645 / 698.45，不做加购。这是「能用」的最低门槛，加购会劝退新客户。

行业协议包：加购

IEC 104、IEC 61850 等加购，原因：

• 工程量大（双向收发、状态机、序号管理）
• 客户需求明确（调度接入项目才用）
• 服务深度高（联调 + 合规）

建议按项目计价，而不是按台：一个项目一笔费用。

厂商专项包：加购

按厂商 + 按台计价。一个项目用了华为 + 阳光 + 锦浪，就按各家台数分别计算。

这样的定价与客户真实使用情况对齐：不会出现「只用 1 家却买了通用包多付钱」，也不会「用了 10 家但单家包不够用」。

四、与 OEM / 厂商的合作模式

按厂商打包还涉及与设备厂家的商业模式：

模式 A：服务商自建协议包

• 服务商工程师反向工程 + 现场测试
• 协议包归服务商所有
• 厂家不参与定价与收益

好处：服务商独立
坏处：覆盖深度受限（拿不到厂家内部文档），新型号支持滞后

模式 B：服务商 + 厂商合作

• 厂家提供完整文档与测试支持
• 协议包仍归服务商
• 厂家不参与终端定价

好处：协议深度好
坏处：合作关系维护成本

模式 C：厂家联合 OEM

• 服务商提供运行时 + 协议适配框架
• 厂家自行开发 / 维护自家协议包
• 收入分账（或厂家支付 SDK 授权费）

好处：覆盖深、新型号跟得快
坏处：商业关系复杂，需要 SDK 标准化

实战中多数项目是 A + B 混合，C 面向战略合作伙伴。

五、长尾厂商怎么处理

中国光伏市场有 200+ 逆变器厂家，长尾怎么办？

选项 1：通用包兜底

• 「Modbus 通用包」覆盖任何符合 Modbus 规约的设备
• 长尾厂家经通用包接入（可能需要客户提供点表）
• 不为单个长尾厂家做 quirks

选项 2：按需求收费

• 客户有特定长尾需求时，按项目报价做接入
• 一次性开发费 + 后续年度维护费
• 适合特定垂直市场（如储能 EMS、充电桩、农业灌溉等）

选项 3：社区贡献

• 开放协议包 SDK，客户 / 第三方贡献接入包
• 平台审核 + 入库 + 分润
• 适合开放生态战略

我们这套方案在 320+ 接入设备品牌的覆盖里基本是混合策略：主流厂商专项包 + 长尾通用包 + 项目级定制。

六、运维与版本管理

协议包不是卖完就结束，需要持续维护：

• 厂家固件升级 → 协议行为变化 → 协议包跟进
• 新型号发布 → 补充 quirks / model 支持
• 安全漏洞 → 修复与更新

这部分成本在「服务保障包」里按年收费，与一次性 License 配套。建议同时做到：协议包版本可追溯（维护一份兼容矩阵），License 与维护解耦（不续维护也可继续使用已购版本）。

七、给商务负责人的建议

1. 不要追求统一颗粒度——混合模式更贴合现实
2. 基础协议包不做加购——加购门槛劝退新客户
3. 维护好主流厂家合作关系——协议深度的根本来源
4. 长尾用通用包兜底——不要每个长尾都做专项
5. 版本维护单独定价——一次性 License + 年度服务保障

TL;DR

协议包授权颗粒度：基础协议包按协议打包（含在基础 License），行业协议包按协议加购，厂商专项包按厂商加购。混合模式最贴合现实。基础 License ¥400/台起，加购模块按需。完整协议矩阵见Zenova EdgeOS 完整方案 →