4. AVEVA System Platform架构与核心对象

AVEVA System Platform（以下简称 System Platform）是面向工业运营的集成化应用平台，其核心价值在于把现场设备、控制逻辑、历史数据、报警与可视化统一组织在一个可复用、可扩展的对象模型中。理解这套平台，关键不是记住菜单在哪里，而是理解四个层次的关系：IDE 是开发环境，Galaxy 是工程数据库，对象模板是复用单元，实例化与部署是把设计变成运行实体的过程。这四者构成了从“设计态”到“运行态”的完整链路。

IDE：设计与调试的统一入口

System Platform 的 IDE（Integrated Development Environment）是工程师进行工程组态的主界面。它并不是一个单纯的画面编辑器，而是同时承载对象建模、脚本编写、模板管理、部署操作和运行诊断的工作台。在 IDE 中，工程师可以打开一个 Galaxy，浏览其对象树，创建模板与实例，编辑属性、脚本和图形，并把变更部署到目标节点。

IDE 的典型工作区包括：对象树/模型视图（展示 Galaxy 内的层级结构）、属性面板（查看和修改对象属性）、脚本编辑器（编写对象级或应用级脚本）、图形编辑器（绘制可视化画面）、部署视图（查看平台、引擎与对象分配关系）。需要强调的是，IDE 中的修改默认只作用于 Galaxy 的工程数据库，不会自动影响正在运行的现场节点，必须通过部署动作才能生效。这一点是初学者最容易混淆的地方。

Galaxy：工程数据库与命名空间

Galaxy 是 System Platform 的工程数据库，可以理解为一个独立的“工程命名空间”。一个 Galaxy 通常对应一个工厂、一条产线或一个明确的工程边界。它保存了所有对象定义、模板、实例、脚本、图形、安全设置和部署配置。Galaxy 本身不是运行实体，而是设计态的数据容器；运行时由部署到各节点的引擎来承载具体对象。

Galaxy 内部采用层级化的对象组织方式，常见层级为：Galaxy → 区域（Area）→ 设备/单元（Equipment/Unit）→ 具体对象。这种层级不仅用于浏览，还直接影响命名空间、安全权限、报警分组和数据访问路径。例如，一个名为 Plant1.LineA.Filler.TempSensor 的对象，其路径本身就表达了位置和归属关系。合理规划 Galaxy 层级，是后续模板复用和批量部署的基础。

对象模板：可复用的工程资产

对象模板（Object Template）是 System Platform 实现工程复用的核心机制。模板定义了一类对象的属性、脚本、报警、历史配置和图形表示。例如，可以创建一个“温度变送器”模板，包含 PV（过程值）、EU（工程单位）、HiHi、Hi、Lo、LoLo 等报警限值，以及对应的历史采集设置和面板图形。

模板分为两类：基模板（Base Template）和派生模板（Derived Template）。基模板定义通用行为，派生模板继承基模板并增加或覆盖特定属性。例如，先建立“模拟量输入”基模板，再派生出“温度变送器”“压力变送器”“流量计”等模板。派生关系形成模板继承树，修改基模板可以影响所有派生模板和实例，但需要谨慎评估影响范围。

模板的价值在于：现场有 50 台同型号泵时，不需要重复创建 50 套属性与脚本，而是创建一个“离心泵”模板，然后实例化 50 次，只修改每台的位号、量程和报警值。这大幅降低了组态工作量和后期维护成本。

实例化：从模板到具体对象

实例化（Instantiation）是指基于模板创建具体对象实例的过程。实例继承模板的全部属性、脚本和图形，同时拥有自己的实例名、层级位置和可覆盖属性。例如，基于“离心泵”模板创建实例 P-101，其 PV 可能来自 PLC1.Pump101.Run，而 P-102 则来自 PLC1.Pump102.Run。

实例化时需要注意三点：第一，实例的命名必须唯一，通常由 Galaxy 层级路径保证；第二，实例可以覆盖模板属性，但覆盖后与模板的继承关系仍然存在，模板变更是否传播取决于属性是否被锁定或覆盖；第三，实例的部署目标需要明确，即该实例由哪个引擎承载。实例化不是复制粘贴，而是建立“模板—实例”的引用关系，这是后续批量修改和统一运维的前提。

部署模型：从设计态到运行态

部署（Deployment）是把 Galaxy 中的对象分配到运行节点并使其生效的过程。System Platform 的部署模型包含三个关键概念：平台（Platform）、引擎（Engine）和对象分配（Object Assignment）。

平台是运行在计算机或虚拟机上的基础服务，负责承载一个或多个引擎。引擎是实际执行对象逻辑的运行时容器，例如 AppEngine 负责脚本、报警、历史等对象行为。对象分配决定 Galaxy 中的哪些实例由哪个引擎承载。一个 Galaxy 可以部署到多个平台和引擎上，实现负载分担和区域隔离。

部署过程通常包括：在 IDE 中建立平台与引擎连接、把对象分配到目标引擎、执行部署、验证运行状态。部署后，IDE 中的设计态对象与运行态引擎中的对象建立映射。若修改了模板或实例，需要重新部署才能让变更生效。部署不是一次性动作，而是贯穿工程生命周期的持续操作。

设计态与运行态的边界

理解 System Platform 架构，最重要的一条边界是：IDE 和 Galaxy 属于设计态，Platform 和 Engine 属于运行态。设计态中的对象是“图纸”，运行态中的对象是“设备”。部署是跨越这条边界的唯一通道。很多现场问题——例如“为什么改了报警值但画面没变化”“为什么新加的对象不产生历史数据”——根源都在于只改了设计态而没有部署，或者部署到了错误的引擎。

因此，日常工程操作应形成固定习惯：在 IDE 中完成修改后，先确认对象所属的引擎和平台，再执行部署，最后在运行态验证对象状态、报警和历史是否正常。部署视图中的对象分配关系，是排查这类问题的第一手依据。

一个可参考的工程组织示例

假设某水处理厂需要监控 3 条产线，每条产线有 2 台进水泵、1 台过滤器、1 个流量计。可以按以下方式组织：

这种组织方式的好处是：模板统一维护，实例只覆盖差异；区域与引擎对应，部署边界清晰；命名路径自带位置信息，便于报警定位和历史查询。实际项目中，模板数量和层级深度应根据设备种类和运维需求平衡，不必追求过细的层级。

总结来看，IDE 提供操作界面，Galaxy 提供工程数据容器，模板提供复用能力，实例化把模板变成具体对象，部署把对象变成运行实体。掌握这条链路，就掌握了 System Platform 工程组织的主干。后续的画面绑定、报警配置、历史采集和脚本逻辑，都是在这条主干上展开的。