📚 课程目录第4章 AVEVA Application Server工程环境搭建

4. AVEVA Application Server工程环境搭建

AVEVA Application Server（以下简称 App Server）的工程环境搭建，本质上是把一套“运行时基础设施”从零建立起来：先创建承载所有工程对象的 Galaxy 数据库，再让 IDE 与 Galaxy 建立可信连接，随后部署 Application Server 实例并分配计算资源，最后通过安全模型把权限收敛到具体角色，并建立可回退的备份机制。这五件事存在严格的先后依赖——没有 Galaxy 就没有可连接的对象仓库，没有平台连接就无法部署实例，没有实例就谈不上角色授权，而备份策略必须从第一天就建立，否则后续所有配置都处于“不可恢复”状态。

一、创建 Galaxy：工程对象的唯一容器

Galaxy 是 App Server 的工程数据库，所有对象（Object）、模板（Template）、实例（Instance）、图形（Graphic）、脚本与安全配置都存放在其中。创建 Galaxy 时需要在 Galaxy Repository 所在机器上执行，典型路径为 C:\Program Files (x86)\AVEVA\Application Server\Bin\galaxy.exe，或通过 IDE 的 Galaxy 管理界面完成。

创建过程中需要确定几个关键参数：Galaxy 名称（建议使用“项目代号_环境”格式，如 LINE2_DEV）、存储路径（默认位于 ...\Galaxy\ 下，每个 Galaxy 一个独立文件夹）、以及初始管理员账号。示例参数如下：

Galaxy Name : LINE2_DEV
Galaxy Path : D:\AVEVA\Galaxy\LINE2_DEV
Admin User  : administrator
Admin Pwd   : 首次登录后强制修改
Platform    : Application Server 2023

创建完成后，Galaxy 会生成一组系统对象，包括 $System、$UserDefined 等命名空间。此时 Galaxy 处于“空工程”状态，只有基础模板，没有任何现场对象。判断创建成功的依据是：IDE 的 Galaxy 列表中能看到该名称，且能进入 Deployment 视图看到默认的 Galaxy 平台节点。

Galaxy 名称一旦创建不建议修改，因为后续平台连接、备份脚本、部署清单都会引用该名称。若必须重命名，应视为一次完整的迁移操作。

二、配置平台连接：让 IDE 找到 Galaxy

平台连接（Platform Connection）解决的是“客户端如何定位并信任 Galaxy”的问题。在 IDE 中通过 Galaxy → Connect to Galaxy 添加连接，需要填写 Galaxy 所在主机名或 IP、Galaxy 名称、以及认证方式。认证方式通常有两种：Windows 集成认证（推荐用于域环境）和 Galaxy 本地账号认证（适用于工作组或调试环境）。

连接配置的核心参数包括：

Host：Galaxy Repository 所在机器，示例 10.20.30.11；
Galaxy：LINE2_DEV；
Authentication：Windows Authentication 或 Galaxy Authentication；
Port：默认由平台服务监听，通常无需手工指定。

连接成功后，IDE 会加载 Galaxy 的对象树。若连接失败，优先检查三项：平台服务（AVEVA Application Server Platform）是否启动、防火墙是否放行、以及当前 Windows 账号是否在 Galaxy 的 $System 安全组中。这三项覆盖了绝大多数“连不上”的排障场景。

三、部署 Application Server：从平台到实例

部署（Deployment）是把 Galaxy 中的逻辑平台模型映射到真实计算节点的过程。在 IDE 的 Deployment 视图中，先创建 Platform，再在 Platform 下创建 Application Server 实例。每个实例对应一个独立的运行时进程，拥有自己的引擎（Engine）、扫描周期和对象命名空间。

部署时需要指定目标计算机（Node）、实例名称、以及启动方式。示例部署结构如下：

Platform : PLT_LINE2
  └─ Application Server : APP_LINE2_01
       Node        : APP-SVR-01
       Engine      : Primary
       Scan Period : 500 ms
       Startup     : Automatic

部署完成后，实例状态会经历 Deployed → Starting → Running 的变化。只有进入 Running，对象脚本才会真正执行。若实例停留在 Deployed 或反复重启，应查看 Windows 事件日志中 AVEVA Application Server 来源的记录，常见原因是节点未加入平台、端口冲突或 Galaxy 路径不可访问。

四、设置安全与用户角色

App Server 的安全模型是“角色—权限—对象”三层结构。角色（Role）定义一组权限，用户或用户组被赋予角色，权限最终作用到对象、区域或操作上。工程中常见的角色划分如下：

角色	典型权限	适用人员
Operator	查看画面、确认报警、写入有限设定值	现场操作员
Engineer	修改对象属性、下载部署、调试脚本	自控工程师
Admin	Galaxy 管理、用户与角色分配、备份恢复	系统管理员

配置时先在 Galaxy 的 $System 下创建用户与用户组，再在 Security 视图中定义角色并绑定权限。一个实用原则是：按最小权限授予，Operator 不应拥有部署权限，Engineer 不应拥有删除 Galaxy 的权限。若使用 Windows 域账号，可直接将域组映射为 App Server 用户组，减少逐人维护成本。

不要用 administrator 账号进行日常画面操作或脚本调试。管理员账号应仅用于工程管理，日常操作使用对应角色账号，这样在审计和排障时才能准确追溯“谁改了什么”。

五、工程备份与恢复

备份不是“做完工程再考虑”的事，而应在 Galaxy 创建后立即建立。App Server 的备份至少包含三部分：Galaxy 数据库备份、部署配置导出、以及自定义脚本与图形资源。Galaxy 备份可通过 IDE 的 Galaxy → Backup 执行，也可用命令行工具做定时任务。

备份内容：
  1. Galaxy 数据库      → LINE2_DEV_20240612.bak
  2. 部署清单           → deployment_PLT_LINE2.xml
  3. 自定义脚本/图形    → Scripts\  Graphics\
恢复顺序：
  Galaxy 还原 → 平台连接重建 → 实例重新部署 → 角色与权限校验

恢复时最容易出问题的环节是“平台连接重建”：因为新环境的机器名或 IP 可能与备份时不同，需要在 IDE 中重新配置 Host 并确认平台服务已启动。恢复完成后，应逐项验证：Galaxy 对象树是否完整、实例是否进入 Running、关键画面能否打开、Operator 账号能否正常登录并操作。只有这四项都通过，才能判定恢复成功。

最后给出一个可执行的检查清单，用于每次环境搭建或恢复后逐项确认：

Galaxy 已创建，名称与路径符合命名规范；
平台服务已启动，IDE 能成功连接；
Application Server 实例状态为 Running；
角色与用户已按最小权限配置；
Galaxy 备份文件已生成并可读取；
恢复演练至少执行过一次，且四项验证全部通过。

把这五步做扎实，后续的对象建模、画面组态和报警配置才有稳定的运行基础；反之，如果 Galaxy 命名混乱、连接靠临时 IP、权限全给管理员、备份从未验证，那么工程规模越大，维护成本会呈指数上升。