📚 课程目录第4章对象建模方法与工具

4. 对象建模方法与工具

在 AVEVA System Platform 中，对象建模不是“画几张图”或“建几个点”的简单操作，而是把现场设备、控制逻辑与可视化表现统一抽象为可复用、可派生、可追溯的工程资产。理解 IDE、对象模板、实例化、派生模板、图形化建模以及版本管理与变更控制之间的关系，是保证项目从单机调试走向多产线复制、从一次性交付走向长期运维的关键。

IDE：对象工程的统一工作台

System Platform 的 IDE（Integrated Development Environment）是对象建模的主入口。它并不是一个单纯的画面编辑器，而是把模型树、模板库、实例部署、图形符号、脚本与版本状态集中在一个工程环境中。典型工作流是：先在 IDE 中建立 Galaxy（工程数据库），再在 Model 视图中创建对象模板与实例，在 Graphics 视图中为对象绑定图形符号，最后通过部署把对象模型下发到目标节点。

IDE 中需要重点区分三个层次：模板层（定义“这类设备长什么样”）、实例层（定义“这台具体设备在哪里、参数是多少”）、部署层（定义“这些对象运行在哪个引擎上”）。很多工程问题并非出在逻辑本身，而是模板、实例与部署关系混乱，导致改一处却影响一片。

对象模板与实例化：从“类”到“对象”

对象模板（Object Template）是建模的复用单元。以一台“离心泵”为例，模板中可以预置：

属性：位号、额定流量、额定扬程、电机功率、启动允许条件；
属性：运行状态、故障状态、电流、出口压力等 I/O 绑定占位；
脚本：启动联锁、故障复位、运行计时；
图形符号：泵体、运行/停止/故障颜色、点击弹出面板。

实例化（Instantiation）就是基于模板生成具体对象，例如 P-101、P-102。实例继承模板的结构与行为，但可以覆盖属性值、绑定实际 I/O、指定所属引擎。实例化的价值在于：同一类设备只维护一份逻辑，现场有多少台泵就生成多少个实例，避免重复编写相同脚本。

需要特别注意的是，实例对模板的继承关系分为“继承”和“覆盖”两种状态。若实例覆盖了某个属性，后续模板变更不会自动改写该实例；若未覆盖，则模板变更会向下传递。工程中应明确哪些属性允许实例覆盖，哪些必须由模板统一控制。

派生模板：在共性之上做差异化

当设备类型出现细分时，不应直接修改基础模板，而应使用派生模板（Derived Template）。例如先建立“通用离心泵”模板，再派生“带变频器的离心泵”模板，在派生模板中增加频率给定、频率反馈、变频故障等属性与脚本。派生模板继承父模板的全部内容，同时允许增加或重写部分定义。

派生模板的工程意义在于：共性上移、差异下放。基础模板负责通用联锁与图形，派生模板负责特殊控制与显示。这样当通用逻辑需要修正时，只需改基础模板，所有派生模板与实例都能按继承规则获得更新。

建议控制派生层级不超过 3 层。层级过深会导致继承链难以追踪，排查“为什么这个实例有这个行为”时成本急剧上升。

图形化建模：让对象模型“看得见”

图形化建模不是独立于对象模型的另一套东西，而是对象模型的可视化映射。在 IDE 中，图形符号通常与对象模板绑定：符号上的动画、颜色、数值显示都通过属性引用与对象实例关联。例如泵的图形符号中，FillColor 绑定到实例的 Status 属性，Text 绑定到 TagName，点击事件打开该实例的面板。

正确的做法是：先完成对象模板与实例的属性定义，再制作图形符号并建立绑定，而不是先在画面上摆一堆图形再反向补对象。图形化建模的核心检查点是“图形是否只引用对象属性，而不硬编码具体值”。硬编码会导致同一符号无法复用到不同实例，失去模板化意义。

模型版本管理与变更控制

对象模型一旦投入运行，任何修改都可能影响正在运行的生产系统。因此必须建立版本管理与变更控制机制。System Platform 中常用的手段包括：Galaxy 备份与恢复、对象模板的签入/签出、变更记录与部署差异对比。

一个可执行的变更控制流程如下：

变更申请：明确要改哪个模板或实例、改什么属性、影响哪些产线；
离线修改：在开发 Galaxy 或测试环境中修改，禁止直接改生产运行库；
差异对比：使用 IDE 的部署差异或对象比较功能，确认实际改动范围；
测试验证：在测试引擎上部署，验证脚本、联锁与图形绑定；
审批与发布：记录版本号、修改人、修改内容、回滚点；
生产部署：选择停机窗口部署，部署后核对关键实例状态。

版本管理的关键不是“备份文件”，而是可追溯：任何一个实例当前行为，都能回溯到它继承自哪个模板、哪个版本、哪次变更。建议在模板命名或属性中保留版本标识，例如 Pump_Centrifugal_V2.3，并在变更记录中写明与上一版的差异。

一个可参考的模板与实例配置示例

以下示例展示“离心泵”模板中关键属性的定义方式，以及实例化时如何覆盖参数。示例参数为教学假设值，实际工程应按设备铭牌与工艺要求填写。

模板：Pump_Centrifugal_V2.3
  属性：
    TagName        : ""            // 实例化时填写
    RatedFlow      : 100 m³/h      // 额定流量
    RatedHead      : 32 m          // 额定扬程
    MotorPower     : 22 kW
    StartPermissive: LevelOK AND NotFault
    Status         : {Stopped, Running, Fault}
  脚本：
    OnStart: IF StartPermissive THEN RunCmd := TRUE
    OnFault: Status := Fault; RunCmd := FALSE
  图形符号：
    FillColor 绑定 Status
    Text      绑定 TagName
    Click     打开面板

实例：P-101
  继承自：Pump_Centrifugal_V2.3
  覆盖：
    TagName   := "P-101"
    RatedFlow := 120 m³/h
    MotorPower:= 30 kW
  绑定：
    RunCmd    → PLC1.P101_Run
    Status    → PLC1.P101_Status
    Fault     → PLC1.P101_Fault
  部署引擎：AppEngine_Line1

在这个示例中，P-101 继承了模板的联锁逻辑与图形符号，只覆盖了与自身设备相关的参数和 I/O 绑定。若后续发现“启动允许条件”需要增加“出口阀开到位”，只需修改基础模板 Pump_Centrifugal_V2.3 并发布新版本，所有未覆盖该逻辑的实例都会按继承规则获得更新。

不要在生产运行库中直接修改模板并立即部署。正确做法是先在测试 Galaxy 中修改、对比差异、验证脚本，再选择停机窗口发布。直接改生产库会导致正在运行的实例行为突变，且难以回滚。

建模质量的关键判断点

完成对象建模后，可以用以下问题自查：模板是否只包含同类设备的共性？实例是否只覆盖真正因设备而异的参数？派生模板是否控制在合理层级？图形符号是否只引用属性而不硬编码？每次变更是否有版本记录、差异对比和回滚点？如果这些问题都能明确回答，对象模型才真正具备可复用、可维护、可追溯的工程价值。