2. AVEVA平台组件与许可体系

多站点监控平台不是把若干软件装到多台服务器上那么简单。它更像一支分工明确的技术团队：有人负责把现场设备抽象成可复用的对象模型，有人负责长期保存过程数据，有人负责把画面呈现给操作员，还有人负责把关键指标送到管理层手机或浏览器上。AVEVA 的 System Platform、Historian、InTouch、AVEVA Insight 正是这支团队中的四类核心角色。理解它们各自“管什么、不管什么”，以及许可在多站点环境下如何分配，是后续所有集成工作的前提。

一、四个组件在多站点架构中的角色分工

System Platform（系统平台）是多站点架构的“骨架与神经中枢”。它提供 Galaxy 存储库、IDE 开发环境、对象模板（Object Template）、实例化机制以及 Application Server 运行引擎。在多站点场景中，通常采用“中央 Galaxy + 各站点 Application Server”的结构：中央 Galaxy 保存统一的设备类型模板（如泵、阀门、罐体），各站点通过部署（Deploy）把模板实例化为本地对象，从而保证不同站点的同类设备具有一致的属性、脚本和报警定义。System Platform 还负责站点间的数据引用与命名空间管理，是跨站点对象复用的基础。

Historian（历史数据库）是“长期记忆”。它通过采集接口（如 OPC DA/UA、MQTT、CSV 导入）把过程值、报警事件、批次信息按时间序列存储，并提供趋势查询、聚合计算和回填能力。多站点环境下，Historian 的部署有两种典型模式：一是各站点独立部署 Historian，中央通过 Historian Client 或跨库查询汇总；二是中央部署一套 Historian，各站点通过 Store-and-Forward 或远程采集节点上传。前者网络依赖低、站点自治性强，后者数据集中、全局分析方便，但需要评估中央节点的吞吐与存储容量。

InTouch是“操作员的眼睛和手”。它负责画面组态、动画连接、报警显示和操作指令下发。在多站点环境中，InTouch 通常与本地 Application Server 配合，通过 ArchestrA 对象引用直接绑定 System Platform 中的属性，而不是逐点建立传统标记名。这样当某个站点的设备模板更新时，画面绑定关系可以随对象模型同步调整。InTouch 的许可通常按“运行节点 + 客户端数量”计算，多站点部署时需要区分本地操作站、远程操作站和 Web 客户端。

AVEVA Insight是“面向管理层的窗口”。它从 Historian 或 System Platform 中抽取关键绩效指标（KPI），以云服务或本地部署方式提供仪表板、趋势对比、报警推送和报表订阅。Insight 不直接连接 PLC，也不承担实时控制职责，它的价值在于把多个站点的同类指标放在同一视图中比较，例如各站点单位能耗、设备可用率、报警次数排名。因此 Insight 的许可重点在于“数据源连接数、用户数、数据保留周期和资产数量”。

二、许可配置的核心逻辑：按“角色”而非按“机器”

很多项目在初期容易把许可理解为“一台服务器一个授权”，结果在扩展站点时发现要么重复购买，要么功能无法启用。AVEVA 的许可体系更接近“按角色授权”：

• System Platform 许可通常与 Application Server 的部署实例、Galaxy 存储库以及开发环境相关。多站点时，如果各站点独立运行 Application Server，则需要为每个运行实例配置相应授权；如果采用中央 Galaxy 统一管理、站点仅作为远程部署目标，则许可集中在中央开发与部署节点上。关键判断依据是：对象模型在哪个 Galaxy 中定义、由哪个 Application Server 执行。
• Historian 许可主要按采集点数（Tag 数）、客户端连接数和存储容量授权。多站点环境下，如果各站点独立 Historian，则每个站点分别计算采集点数；如果中央 Historian 汇聚所有站点，则总采集点数是各站点之和，并需要额外评估 Store-and-Forward 缓冲和网络中断后的回填能力。
• InTouch 许可分为开发版、运行版和客户端版。运行版通常绑定到具体操作站节点，客户端版按并发或命名用户计算。多站点时，本地操作站使用运行版，远程监控室或 Web 访问使用客户端版。需要注意：InTouch 通过 ArchestrA 对象引用访问 System Platform 数据时，不额外消耗传统标记名许可，但运行节点本身仍需授权。
• AVEVA Insight 许可通常按资产数量、数据源连接数和用户数组合授权。它不替代 Historian，而是从 Historian 或 System Platform 中读取已聚合的数据。多站点时，应明确哪些 KPI 需要上传、上传频率是多少、保留多久，再据此选择许可规模。

三、多站点许可配置的实操要点

假设一个示例场景：三个工厂站点，每站约 5000 个过程点，各站有 2 个本地操作站，中央需要汇总 20 个 KPI 供管理层查看。配置时可按以下思路推进：

1. 先确定 Galaxy 拓扑。若三个站点设备类型高度相似，建议中央建立统一 Galaxy，各站点部署 Application Server 并继承模板。此时 System Platform 许可集中在中央开发节点和三个站点运行实例上。
2. 再确定 Historian 模式。若站点网络不稳定，采用各站独立 Historian，每站按 5000 点授权；中央通过 Historian Client 或跨库查询读取汇总数据。若网络可靠且需要全局趋势，采用中央 Historian，按 15000 点总量授权，并配置 Store-and-Forward 防止断网丢数。
3. 然后分配 InTouch 许可。每站 2 个本地操作站使用运行版授权；中央监控室若需要同时查看三个站点画面，按远程客户端数量授权。若使用 Web 客户端，需确认 Web 服务器与客户端许可是否已包含在所选套件中。
4. 最后规划 Insight 许可。只上传 20 个 KPI 时，资产数量和数据源连接数需求较小；但若后续扩展到设备级健康指标，需预留资产数量余量。Insight 的用户数按实际需要查看仪表板的管理人员计算，避免按全员授权造成浪费。

四、常见误区与判断依据

第一个误区是把 Insight 当作 Historian 使用。Insight 适合展示聚合后的 KPI，不适合存储高频原始过程数据；如果试图用它替代 Historian，会在数据精度和查询性能上遇到瓶颈。第二个误区是忽略 System Platform 的部署许可与开发许可区别。开发环境可以集中，但每个运行 Application Server 的站点节点通常都需要运行授权。第三个误区是 Historian 点数按“设备数”而非“采集点”估算。一台泵可能包含温度、压力、流量、振动等多个采集点，许可计算应以实际 Tag 数为准。

判断许可是否配置合理，可以观察三个信号：一是部署时是否出现“授权不足”导致对象无法部署或 Historian 采集停止；二是跨站点查询时是否因客户端许可不足而无法同时打开多个站点的趋势；三是 Insight 仪表板是否因资产数量超限而无法添加新设备。出现这些信号时，应回到“角色—节点—许可”对照关系重新核对，而不是简单增加某一类授权数量。

总体而言，System Platform 负责统一模型与运行骨架，Historian 负责数据持久化，InTouch 负责人机交互，Insight 负责管理级可视化。多站点许可配置的关键，是先明确每个组件在哪个站点、哪个节点、以什么角色运行，再按角色匹配许可类型和数量。把这条主线理清，后续的站点集成、数据汇聚和画面发布才能稳定推进。