Aspen HYSYS 二次开发系列教程（10）：Event Scheduler 与 ASW 的免编程边界
版本声明块
- 软件：aspenONE V15（基线，同第 1 篇）；文档现实：Customization Guide V7.3（2011-03）为公开手册基线
- 语言/环境：HYSYS GUI + Excel（ASW）；脚本路线对照见第 8 篇闭环五步
- 本文目标：给出免编程与脚本两条路线的分工判据表，避免用错工具付返工代价
一句话结论：Aspen Simulation Workbook（ASW）解决"单工况参数化+Excel 报表联动"，Event Scheduler 解决"事件时序驱动（阀、泵动作的时间序列）"——两者都表达不了"求使目标函数最小的操作点"这类迭代寻优；分工判据是：问题含多变量全局目标时只有 COM 自动化+外层优化器可执行（第 8/17 篇）。
〇、本篇要解决的认知问题
- ASW 的数据交换方向是什么？它和脚本路线在"求解触发"上的差别是什么？
- Event Scheduler 的事件模型包含什么——事件、时刻、动作三要素如何映射到对象模型？
- 免编程路线的三个天花板（寻优、系统集成、审计链）分别对应哪条工程纪律？
- 什么时候应该从 ASW 升级到脚本——升级判据是什么？
- 两条路线混用时的最大风险是什么（双写入源冲突）？
一、机制解析
1.1 ASW 的方向性与求解触发（价值锚点：选错工具的第一代价是"扫描表跑不动"）
ASW: Excel(输入/工况表) ⇄ HYSYS case(对象) ← 双向数据交换（第 16 篇方向性约定） 脚本: Python/VBA → COM 对象 → Run → 断言 → 取值 ← 求解触发与状态检查在脚本层（铁律 6）ASW 的"扫描表"本质是逐点重算——它不改变流程求解结构，也不提供多变量寻优；第 8 篇闭环五步的判优环节在 ASW 里没有对应物。这解释了"为什么 ASW 能出漂亮报表但做不了优化"。
1.2 Event Scheduler 的事件模型（三要素）
| 要素 | 语义 | 对象模型映射（以本机为准） |
|---|---|---|
| 事件触发条件 | 达到某物理量阈值或时刻 | 依赖 case 内可访问的物理量成员——未证实处标注（铁律 7） |
| 动作 | 改变设备/流股状态（开阀、停泵） | 写入输入侧成员（第 9 篇输入/解边界） |
| 时序结构 | 顺序/并行时间关系 | 动态 case 的时间推进语义（第 12 篇） |
Event Scheduler 是"操作序列的 GUI 化"——与 gPROMS task language（Elementary tasks + timing structures）同思路（跨主题线，见母索引）；但它不回答"什么操作序列最优"。
1.3 三个天花板的工程对应表
| 天花板 | 表现 | 对应脚本纪律 |
|---|---|---|
| 多变量寻优 | 只能逐点跑表 | 闭环五步+外层优化器（第 8/17 篇） |
| 系统集成（服务/定时/数据库） | 依赖 GUI 环境 | 无 GUI 部署形态（第 4/15 篇） |
| 审计链（状态字段、时间戳、版本快照） | 报表无状态列 | 断言层与输出层校验（第 6/13/19 篇） |
1.4 升级判据与混用风险
升级判据（满足其一即升级到脚本）：① 问题含两个以上操纵变量+一个全局目标；② 需要无人值守运行或数据库回写；③ 需要可审计的状态字段。
最大混用风险：双写入源冲突——ASW 与脚本同时改同一对象时，谁最后写入谁生效，结果不可复现（第 19 篇命名与所有权约定在此闭环）。经验法则：一个 case 只允许一个写入源；报告注明写入源类型。
二、完整实战：同一问题的两条路线对照
问题（示例工况）：使冷凝器负荷最小的回流比，约束纯度 ≥0.95。
- ASW 路线：把回流比做成 Excel 输入列、纯度与负荷做成输出列，跑扫描表。判定标准：只能得到"逐点响应"——无法自动选出满足约束的最优点；报告里必须人工判读。
- 脚本路线（第 8 篇形态）：evaluate() 含惩罚值判优。判定标准：自动给出最优行且每行带状态字段——这就是天花板差异的直接演示。
- Event Scheduler 对照：同一 case 用事件定义"某时刻改变回流比"。判定标准：它回答"时序上会发生什么"，不回答"哪个值最优"——三要素表（1.2）逐项对应即达标。
判定线汇总：ASW 路径人工判读、脚本路径自动判优、Event Scheduler 路径只有时序响应——三条输出形态互不相同且不可互相替代。
三、常见报错与排查
- 双写入源冲突—— 现象：同一对象值与预期不符且不可复现（1.4）。根因：ASW 与脚本同时写入。解法：一个 case 单一写入源；所有权写入文档（第 19 篇）。
- 扫描表列错位—— 现象：输入列被当输出读。根因：方向性约定不固定（1.1、第 16 篇）。解法：固定列命名与方向注释，报表生成前手工抽查一次。
- 事件条件引用不可确证的成员名—— 现象：事件不触发或报错。根因：物理量成员名未在本机 dir() 清单内（铁律 7）。解法：先枚举再引用；把确证清单存档。
- 动态事件与时域读取时机错—— 现象：读到事件前时刻的值。根因：时间推进未完成即读结果（第 9/12 篇）。解法：事件到达后读取；断言推进状态（成员名以本机为准）。
四、动手练习
- 两路线对照复现：按第二节完成三条输出形态对照。判定标准：三种形态互不相同且不可互相替代——能指出"人工判读 vs 自动判优 vs 时序响应"的分工。
- 升级判据应用：给一个含两个操纵变量的问题（回流比+进料板位置），按 1.4 判断应走哪条路线并写出依据。判定标准：判据命中条目明确；给出最小脚本改动点（evaluate 增加一维变量）。
- 思考题（无标准答案）：为什么"一个 case 单一写入源"是硬纪律？验证要点清单：① 写出双写入源的不可复现机制；② 举一个审计链被破坏的场景（状态字段与实际写入者不一致）；③ 给出报告应记录的三项信息（写入源类型、时刻、版本）。
五、小结与下一篇预告
本篇把免编程路线的边界钉死为三个天花板与升级判据，确立"单一写入源"纪律。第 11 篇进入 CAPE-OPEN UDM——自研单元装进流程的另一条代码路径（铁律 8：与 COM 脚本不共享任何一行调用代码）；第 12 篇集中处理稳态 vs 动态的对象陷阱。
本篇认知问题回显（FAQ）
Q1：Aspen Simulation Workbook（ASW）能做什么、做不了什么？
A：ASW 解决单工况参数化与 Excel 报表联动（双向数据交换），扫描表本质是逐点重算；它表达不了"求使目标函数最小的操作点"——多变量迭代寻优只有 COM 自动化+外层优化器可执行。
Q2：Event Scheduler 的事件模型包含什么？
A：三要素——事件触发条件（物理量阈值或时刻）、动作（改变设备/流股状态，写入输入侧成员）、时序结构（顺序/并行时间关系）；它回答"时序上会发生什么"，不回答"哪个值最优"。
Q3：免编程路线的三个天花板分别对应哪条脚本纪律？
A：多变量寻优→闭环五步+外层优化器（惩罚值判优）；系统集成→无 GUI 部署形态与许可管理；审计链→断言层与输出层的状态字段、时间戳、版本快照。
Q4：什么时候应该从 ASW 升级到脚本？
A：满足其一即升级——问题含两个以上操纵变量加一个全局目标；需要无人值守运行或数据库回写；需要可审计的状态字段（系列口径）。
Q5：ASW 与脚本混用时的最大风险是什么？
A：双写入源冲突——同一对象被两条路线同时写入时谁最后写入谁生效，结果不可复现；纪律是一个 case 只允许一个写入源，报告记录写入源类型、时刻与版本。
