📚 课程目录第3章 AVEVA System Platform与InTouch集成基础

3. AVEVA System Platform与InTouch集成基础

AVEVA System Platform（以下简称 System Platform）与 InTouch 的集成，本质上不是两个软件之间的简单"对接"，而是把 InTouch 从单机 HMI 提升为 System Platform 分布式架构中的一个可视化客户端。要理解这种集成，必须先看清 System Platform 自身的工程结构：Galaxy、IDE、Automation Object、AppEngine、ViewApp 与 InTouch View 各自承担什么职责，以及它们之间的引用关系。只有把这条结构链理顺，后面讨论 System Platform 与 PI System、MES、ERP 的接口边界时，才不会把"平台内部集成"和"平台对外集成"混为一谈。

一、Galaxy：整个工程的容器

Galaxy 是 System Platform 中最顶层的工程数据库，可以把它理解为一个"工程宇宙"。一个 Galaxy 里存放着本项目的所有对象模板、实例、部署关系、安全模型和通信配置。它由 Galaxy Repository（GR）承载，通常运行在 SQL Server 之上，工程师通过 IDE 连接 GR 进行组态。Galaxy 的边界非常关键：同一个 Galaxy 内的对象可以互相引用、可以统一部署；跨 Galaxy 的对象默认不能直接引用，需要借助外部引用或网关。因此在实际项目中，"一个厂区一个 Galaxy"还是"多厂区共享一个 Galaxy"，会直接影响命名空间、部署粒度和后期维护成本。

二、IDE：组态与部署的工作台

IDE（Integrated Development Environment）是工程师实际操作的界面。它提供几个核心视图：Model 视图用于浏览 Galaxy 中的对象树，Deployment 视图用于把对象分配到具体的 AppEngine 或 ViewApp 实例，Object Editor 用于编辑 Automation Object 的属性、脚本和图形。IDE 本身不运行生产逻辑，它只是"设计态"；真正跑起来的是部署后的"运行态"。理解设计态与运行态的分离，是理解 System Platform 的关键——你在 IDE 里改的是模板和实例定义，只有执行 Deploy 之后，变化才会下发到运行节点。

三、Automation Object：可复用的工程单元

Automation Object 是 System Platform 的建模核心。它把"一个设备或一段工艺"封装成带属性（Attribute）、脚本（Script）、报警（Alarm）和历史（History）的对象。Automation Object 分为两类：模板（Template）定义结构与行为，实例（Instance）继承模板并绑定具体值。例如可以建一个"泵"模板，包含 Run、Fault、Speed 三个属性，再派生出 Pump_101、Pump_102 两个实例。属性还分输入输出方向：Input 属性接收来自 PLC 的值，Output 属性可写回，InOut 属性双向。这种"模板—实例—属性"的三层结构，使得同一类设备只需维护一份逻辑，大幅降低重复组态。

四、AppEngine 与 ViewApp：运行态的两条腿

AppEngine 是 Automation Object 的运行宿主，负责执行脚本、扫描属性、产生报警与历史数据。一个 Galaxy 可以部署多个 AppEngine，分布在不同服务器或虚拟机上，实现负载分担与冗余。ViewApp 则是可视化运行宿主，它承载由 InTouch View 生成的画面，并把画面中的元素绑定到 Automation Object 的属性上。AppEngine 管"逻辑与数据"，ViewApp 管"呈现与操作"，两者通过 Galaxy 的命名空间通信，而不是通过传统的 DDE 或点对点标签。这正是 System Platform 集成 InTouch 与传统 InTouch 独立运行最大的区别。

五、InTouch View：画面层的落地形式

在 System Platform 环境中，InTouch 以 InTouch View 的形式存在。它不再是独立的 InTouch 应用，而是作为 ViewApp 的一部分被部署。画面中的对象通过 ArchestrA 引用（如 Me.Pump_101.Speed 或 Galaxy:Plant1.Pump_101.Speed）直接访问 Automation Object 属性，无需再手工建标签、做 I/O 映射。这意味着：改一个模板属性，所有引用它的画面自动生效；改一个实例值，画面与逻辑同步更新。InTouch View 的工程文件（.aaPKG 等）随 Galaxy 一起管理，版本一致性由平台保证。

六、与 PI System、MES、ERP 的典型接口边界

把平台内部结构理清后，对外接口边界就清楚了。System Platform 与外部系统的交互，通常不发生在 InTouch View 画面层，而是发生在 AppEngine 或平台级服务层。典型做法有三类：

与 PI System 集成：历史数据方向以 AppEngine 的 History 存储为源，通过 OPC DA/HDA 或 PI Interface 把属性值写入 PI Data Archive；反向则通过 PI AF 或 PI Web API 把 PI 中的计算值读回 Automation Object 属性。边界应划在"属性级"，而不是画面级，避免画面直接连 PI 造成耦合。
与 MES 集成：MES 关心工单、批次、物料消耗与生产实绩。通常由 AppEngine 脚本在批次开始/结束时，通过 Web Service、MQ 或数据库中间表，把 Automation Object 中的产量、状态、报警汇总推送给 MES；MES 下发的工单参数则写回指定属性。边界应明确"谁触发、传什么字段、失败如何重试"。
与 ERP 集成：ERP 侧重订单、物料主数据与成本。集成频率低、数据量大，一般走中间数据库或消息队列，由平台侧定时任务批量同步，而不是实时逐点交互。边界应划在"业务对象级"，如订单号、物料号、数量，而非设备属性。

判断接口边界是否合理，可以用一句话检验：平台内部用 ArchestrA 引用，平台外部用标准协议或中间件。如果发现 InTouch View 画面里直接写了 PI 或 MES 的连接串，说明边界被打破了，后期维护会非常困难。

七、一个可参考的部署与接口配置示例

假设某水厂项目：1 个 Galaxy，2 台 AppEngine 服务器（一主一备），1 台 ViewApp 服务器，PI System 与 MES 各一套。可参考如下配置思路（参数为示例假设，非实测值）：

Galaxy: WaterPlant
├─ AppEngine_Primary   (节点: APP-01, 扫描周期 500ms)
├─ AppEngine_Standby   (节点: APP-02, 冗余热备)
├─ ViewApp_HMI         (节点: HMI-01, InTouch View 画面)
├─ Template: Pump      (属性: Run, Fault, Speed, Flow)
├─ Instance: Pump_101  (绑定 PLC 地址, 启用 History)
└─ Instance: Pump_102

对外接口（示例）:
  PI System : AppEngine_Primary → OPC DA → PI Interface → PI Data Archive
              采样周期 1s, 仅上传 Run/Fault/Speed/Flow 四个属性
  MES       : AppEngine 脚本 → Web Service → MES 批次接口
              触发点: 批次开始 / 批次结束, 字段: BatchID, Product, Qty
  ERP       : 平台定时任务 → 中间表 → ERP 物料同步
              频率: 每 15 分钟一次, 字段: MaterialCode, OrderNo, Qty

部署完成后，判断集成是否成功的观察点有三个：一是 IDE 的 Deployment 视图显示所有对象状态为"已部署"且无红色告警；二是 InTouch View 画面中 ArchestrA 引用能实时刷新，且与 AppEngine 属性值一致；三是 PI、MES、ERP 侧能收到预期数据，且断线重连后不丢关键批次记录。若画面值不刷新，优先检查 ViewApp 与 AppEngine 是否在同一 Galaxy 命名空间下、引用路径是否拼写正确；若外部系统收不到数据，优先检查接口触发条件与网络端口，而不是先怀疑画面。