一套“嵌入式硬件 + 物联网”可视化，如何计算Highcharts许可证数量？

企业软件采购与授权合规实务，如何计算 Highcharts 许可证？

在智能水表、智慧水务、物联网、能源管理等项目中，Highcharts 经常同时出现在两个不同层面：

嵌入式智能水表、网关或终端设备
物联网运营中台、Web 管理平台或 SaaS 系统

这两个场景虽然都使用 Highcharts 进行数据可视化，但在商业交付模式上可能完全不同，因此不能简单按照"水表有多少块，就购买多少套 Highcharts"来计算许可证。

真正需要判断的是：

Highcharts 最终在哪里运行？谁可以使用？软件是否随产品交付？客户是否可以部署或获得软件？这是内部系统、SaaS 平台，还是 OEM 产品？

本文以"嵌入式智能水表 + 物联网运营中台"这一典型项目为例，说明企业在进行 Highcharts 商业授权评估时应该如何拆分。

一、先理解：Highcharts 许可证不是简单按照"图表数量"计算

企业在采购 Highcharts 时，一个非常常见的误区是：

"我们的项目有 10 万块智能水表，所以 Highcharts 是否需要购买 10 万份？"

实际上，许可证评估通常首先关注的是软件的使用和交付方式，而不是单纯的图表数量。

例如：

场景 1：企业内部研发系统

企业内部开发人员使用 Highcharts 开发水务数据分析平台，最终系统只供企业内部员工使用。

这种情况下，需要重点评估 Internal 使用场景。

场景 2：运营中台由企业统一托管

企业建设一个统一的物联网运营平台：

text 复制代码

智能水表
    ↓
物联网网关
    ↓
IoT平台
    ↓
数据服务
    ↓
运营中台
    ↓
水务公司 / 物业 / 企业客户

Highcharts 运行在企业自己的 Web 平台中，客户通过浏览器访问。

这种情况下，需要重点判断是否属于 SaaS / 外部应用场景。

场景 3：Highcharts 被打包进智能水表产品

如果 Highcharts 被集成到设备端软件、网关软件、嵌入式 HMI 或随设备交付的软件中，那么问题就发生了变化。

因为 Highcharts 不再只是企业内部开发工具，而是随着商业产品一起交付给客户。

此时通常需要重点评估 OEM 授权。

二、智能硬件项目应该拆成两个授权场景

对于典型的"智能水表 + 物联网运营中台"项目，可以先建立下面的分析模型。

产品/系统	Highcharts运行位置	典型交付方式	重点评估
智能水表	设备屏幕/HMI	随硬件销售	OEM
智能水表网关	网关Web UI	随设备/系统交付	OEM
手机App	企业自己的App	面向客户提供	根据交付模式确认
物联网运营中台	企业服务器/云平台	SaaS/平台服务	SaaS / External Application
企业内部管理系统	企业内部服务器	内部使用	Internal
客户私有云部署平台	客户服务器	软件交付	OEM / Customer Installation

因此，第一原则是：

先拆产品和部署场景，再计算许可证，而不是先计算设备数量。

三、场景一：Highcharts嵌入智能水表硬件

假设一家智能水表企业开发了一款具有液晶屏或触摸屏的智能水表。

设备可以显示：

当前用水量
历史用水量
日/月/年统计
峰谷用水
异常用水
流量变化曲线
告警信息
能耗趋势

如果这些图表由 Highcharts 在设备端运行，那么需要重点判断：

Highcharts 是否随商业硬件产品一起交付？

例如：

text 复制代码

Highcharts
     ↓
嵌入式软件
     ↓
智能水表
     ↓
销售给水务公司

这与企业内部开发测试存在本质区别。

企业内部使用 Highcharts 开发软件，并不意味着可以自动把 Highcharts 组件随另一个商业产品无限制地分发给客户。

因此，这类场景通常应该向 Highsoft 明确申请或确认 OEM License。

四、OEM授权为什么与普通开发授权不同？

OEM（Original Equipment Manufacturer）场景的核心特征与天然定价优势：

Highcharts 成为另一个商业产品的一部分，并随该产品向客户交付。

Highcharts OEM许可定价是低于同单位数量的开发者许可和应用许可，并随着采购数量的增加而单价递减，是理想的多终端使用许可类型，并支持不限数量授权。

例如：

智能水表
智能燃气表
智能电表
IoT网关
工业设备
医疗设备
车载终端
自助终端
工业HMI

都可能出现类似问题。

可以简单理解为：

text 复制代码

普通开发

企业
 ↓
Highcharts
 ↓
企业自己的软件
 ↓
企业内部使用


OEM

Highcharts
 ↓
企业软件
 ↓
智能水表/网关/设备
 ↓
最终客户

第二种情况下，软件已经进入商业产品交付链条，因此授权模式需要单独确认。

五、那么OEM到底按照多少计算？

这里最容易出现另一个误区：

"是不是一块水表对应一个Highcharts许可证？"

不能简单这样理解。

OEM项目需要根据实际授权条款确认具体计量方式，例如：

产品型号
产品线
Customer Installation
产品分发范围
出货规模
客户数量
软件部署方式
是否允许客户二次开发

因此，在向 Highsoft 询价时，不建议只提供：

"我们有10万块水表。"

而应该提供完整的商业模型。

例如：

产品信息

产品：智能监控水表

预计：

产品型号：3种
年出货量：100,000台
客户：20家水务企业
Highcharts运行位置：设备端HMI
是否随硬件交付：是
是否允许客户修改系统或图表：否------即是否与许客户二次开发

这样 Highsoft 才能够根据实际产品交付方式判断 OEM 授权模式。

六、场景二：物联网运营中台

第二个场景通常是企业建设统一的物联网运营平台。

例如：

text 复制代码

             智能水表
                ↓
          IoT数据采集平台
                ↓
          数据处理/存储
                ↓
        ┌──────────────┐
        │ 运营管理中台 │
        └──────────────┘
          ↓     ↓     ↓
       水务公司 物业  企业客户

中台可能包括：

实时监控
水表地图
用水趋势
区域统计
异常分析
漏损分析
报表
KPI Dashboard
告警中心
客户管理
设备管理

Highcharts 可以承担其中大量数据可视化工作。

这时最重要的问题变成：

运营中台是谁运营？谁访问？软件是否交付给客户？

七、企业自己托管的SaaS平台

假设企业建设一个统一的云端运营平台。

例如：

text 复制代码

                    云平台
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
    客户A租户       客户B租户       客户C租户
       │              │              │
    10000水表       50000水表       30000水表

所有客户通过浏览器访问同一个平台。

这种情况下，不能简单认为：

10万块水表 = 10万个Highcharts授权。

因为水表本身并没有运行 Highcharts。

Highcharts 实际运行的位置是：

企业托管的Web/SaaS应用。

因此，需要按照 SaaS / 外部应用的商业授权方式与 Highsoft 确认。

八、多租户SaaS平台尤其需要注意

假设企业只有一个物联网运营平台，但是服务：

水务集团A
水务集团B
物业公司C
园区D
工业客户E

从技术架构上看可能仍然是：

text 复制代码

                    一个SaaS平台
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
        Tenant A       Tenant B       Tenant C

这与开发三套完全独立的软件系统，是两个不同的问题。

因此，企业在申请商业授权时应该明确说明：

这是一个统一的多租户SaaS平台，还是多个独立商业应用？

不要简单地用"客户数量"替代"应用数量"。

最终如何计量，需要以 Highsoft 对具体授权模式的确认以及 License Statement 为准。

九、第三种情况：平台部署到客户自己的服务器

还有一种情况特别容易被忽略。

企业开发物联网平台之后，不采用SaaS模式，而是：

直接部署到水务集团自己的私有云或服务器。

例如：

text 复制代码

软件公司
   │
   │ 软件交付
   ↓
水务集团私有云
   │
   ├── 水表管理
   ├── 数据分析
   ├── Dashboard
   └── 报表

这时虽然软件仍然是企业开发的，但运行环境已经变成了客户控制的基础设施。

因此不能简单按照"我们是软件开发公司，所以属于Internal License"处理。

需要重点向 Highsoft 确认：

是否构成客户端安装；
是否属于 OEM；
客户是否获得软件安装权；
客户是否可以二次开发；
一个客户多个环境如何计算。

十、三种模式放在一起看

可以建立一个非常简单的判断模型。

模式	Highcharts运行位置	软件是否交付客户	重点评估
企业内部研发平台	企业内部	否	Internal
企业托管SaaS	企业云平台	否	SaaS / External Application
客户私有云	客户服务器	是	OEM / Customer Installation
智能水表设备	水表设备	是	OEM
IoT网关	网关	是	OEM
企业统一运营中台	企业云平台	否	SaaS / External Application
客户本地部署版	客户服务器	是	OEM / Customer Installation

这张表实际上比"水表数量"更加重要。

十一、一个完整项目可能同时需要两种授权

假设某企业的项目是：

100万块智能水表 + 统一物联网运营平台。

架构如下：

text 复制代码

             ┌───────────────────┐
             │  智能水表100万台    │
             │ Highcharts        │
             └─────────┬─────────┘
                       │
                       ↓
                 IoT数据平台
                       │
                       ↓
             ┌───────────────────┐
             │ 物联网运营中台      │
             │ Highcharts        │
             └─────────┬─────────┘
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
        客户A         客户B         客户C

此时实际上是两个授权问题：

第一部分：设备端

Highcharts 随智能水表产品交付。

重点：

OEM License

第二部分：运营中台

Highcharts运行在企业托管的平台中，对外提供服务。

重点：

SaaS / External Application

所以不能把整个项目简单写成：

"100万水表，采购100万份Highcharts。"

也不能反过来认为：

"我们有SaaS平台，所以水表端也可以直接使用同一个SaaS授权。"

两个使用场景应该分别分析。

十二、采购时应该给Highsoft提供哪些信息？

对于大型物联网项目，建议准备一份 License Assessment 表。

1. 产品信息

项目	示例
产品名称	XXX智能监控水表
产品型号	WM-01 / WM-02 / WM-03
出货量	100,000
生命周期	5~10年
Highcharts运行位置	嵌入式HMI

2. SaaS平台信息

项目	示例
平台名称	智慧水务IoT运营平台
部署方式	企业云平台
用户类型	水务公司/物业
是否多租户	是
软件部署数量	50
是否对外收费	是
Highcharts应用数量	根据实际产品架构说明
是否允许客户创建应用	根据实际情况说明

3. 客户部署信息

如果存在私有化部署，还应增加：

客户数量；
每个客户部署数量；
是否测试环境；
是否生产环境；
是否客户自主运维；
是否允许客户二次开发；
是否允许客户再分发。

十三、Highcharts授权评估的核心逻辑

可以把整个判断过程浓缩成下面这张流程图：

text 复制代码

                是否使用Highcharts？
                       │
                       ↓
                Highcharts运行在哪里？
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       企业内部       企业云平台     客户设备/服务器
          │            │            │
          ↓            ↓            ↓
       Internal    SaaS/External    OEM/
                                  Customer
                                  Installation

然后继续判断：

text 复制代码

是否随商业产品交付？
        │
    ┌───┴───┐
    否      是
    │        │
    ↓        ↓
 SaaS/     OEM
 Internal

最后再结合：

产品数量
客户数量
应用数量
客户端安装数量
多租户模式
部署环境
分发模式
二次开发权

确定具体授权范围。

FAQ、企业最容易犯的5个错误

错误1：按照水表数量直接计算

100万块水表并不必然意味着需要100万份Highcharts许可证。

首先应该确认 Highcharts 是否实际运行在每块水表上。

错误2：认为"软件是自己开发的"就可以内部授权

如果软件已经作为商业产品交付给客户，授权模式可能已经从 Internal 使用转变为 OEM 或其他商业交付模式。

错误3：认为SaaS授权可以覆盖设备端

运营平台使用SaaS授权，并不意味着可以自动覆盖嵌入式设备中的Highcharts。

两个运行环境应该分别进行授权分析。

错误4：只告诉供应商客户数量

"我们有100个客户"并不能完整说明授权规模。

还需要说明：

是100个独立应用、100个租户，还是一个多租户平台服务100个客户？

错误5：忽略私有化部署

SaaS和私有化部署是两个完全不同的商业交付模型。

如果平台部署到了客户自己的服务器、私有云或数据中心，应当在采购前单独确认授权范围。

最终建议：用"产品 + 部署 + 交付"的模型计算

对于智能水表和物联网项目，我更建议企业内部建立一个统一的Highcharts授权评估模型：

第一维：产品

智能水表
IoT网关
移动App
Web运营平台
SaaS平台
私有化平台

第二维：部署

企业内部
企业公有云
企业私有云
客户私有云
客户服务器
嵌入式设备

第三维：交付

内部使用
SaaS服务
软件授权
随硬件交付
OEM产品
客户二次开发

最终形成：

产品 × 部署 × 交付 → License类型 → 授权计量单位 → 具体数量

这比单纯按照"水表数量"计算许可证更加准确。

结语

"嵌入式智能水表 + 物联网运营中台"是一个非常典型的企业级Highcharts授权场景。

它最大的特点是：

同一个项目中，可能同时存在OEM、SaaS/External Application、Internal以及Customer Installation等不同授权场景。

因此，在正式采购之前，建议不要直接拿设备数量套价格，而应该先画清楚：

text 复制代码

产品
 ↓
Highcharts运行位置
 ↓
部署环境
 ↓
最终用户
 ↓
软件是否交付
 ↓
是否允许客户安装/修改/再分发
 ↓
License类型
 ↓
授权计量方式

尤其对于大型智慧水务、能源物联网、智能制造、工业设备等项目，建议在签署 License Statement 前，把产品名称、部署方式、应用数量、客户安装数量、SaaS模式、OEM产品以及客户二次开发权全部写清楚。

最终的授权范围和计费方式，应以 Highsoft 针对具体项目出具的商业报价和 License Statement 为准，而不能仅凭设备数量自行推导。