版本声明本篇基线为AVEVA E3D Design 3.1涉及前代AVEVA PDMS处显式标注。来源性质说明本篇的官方原文引用出自《Pipe Stress Interface User Guide》。本次调研取得该文本的途径是第三方托管副本pdfcoffee.com不是help.aveva.com官方站页面。因此该段原文应视作官方文档文本 第三方托管引用时须保留此标注。原文语境是PDMS文中写作 “one or more PDMS branches”。在 E3D Design 语境下该应用在本机的可用性与具体界面以实际安装为准——请勿假定两者完全一致。未找到的事实如实交代本次调研未找到 E3D/PDMS 与 AVEVA Process Simulation或 Aspen/HYSYS 类流程模拟软件之间基于 PML / .NET 的官方数据对接 API 文档。本篇不涉及该方向也不做任何推测。本篇脚本按通用 PML 语法与纯文本处理构造标注需在本地 E3D Design 环境验证所有数量、行数、时间戳一律为示意真实值须在本机跑出。一句话结论PSI 与应力分析之间的对接是文件级的而不是 API 级的——所以这条链路上二次开发的着力点是把应力组组织干净、把导出前后的差异核对清楚而不是调用应力分析软件的接口。〇 认知问题PSI 到底在哪一层工作它是在 PDMS Design 里跑的还是在 CAESAR II 里跑的什么叫应力组为什么它必须由一个或多个 PDMS branch组成而不能是随便框几个元件CII 文件和_A文件是什么关系既然都是文件中间为什么非要转一次应力分析做完之后结果是怎么回到三维模型里的这一步步是二次开发写的还是应用自己做的这条链路上二次开发到底能做什么、不能做什么我的脚本边界应该划在哪里一 机制解析1.1 官方原文链路《Pipe Stress Interface User Guide》对整条链路的原文描述是“The PSI application allows the user to build stress groups configurations consisting of one or more PDMS branches and transfer the geometry and relevant attributes to and from the Caesar pipe stress package… When a stress group has been created the PSI application will create a CAESAR II CII format file, which can be selected in CAESAR II and converted to a CAESAR II _A format file. Once the stress engineer has finished the analysis; he can create a report file…”来源https://pdfcoffee.com/pipe-stress-interface-user-guide-pdf-free.html 来源性质官方文档文本的第三方托管副本把这段话抽成链路就是五步① 在三维设计环境里建应力组一个或多个 branch ↓ ② PSI 由应力组生成 CAESAR II CII 格式文件 ↓ ③ 在 CAESAR II 中选取该 CII 文件转换成 CAESAR II _A 格式文件 ↓ ④ 应力工程师完成分析生成报告文件 ↓ ⑤ 几何与相关属性to and from——荷载工况/变形结果回写到支管请特别注意原文里两个容易被忽略的动词“transfer … to and from”—— 这条链路是双向的。不只是导出去做分析还包括分析结果回来。“consisting of one or more PDMS branches”——应力组的最小单位是 branch不是元件、不是管线也不是我在屏幕上框选的一堆东西。这句话直接决定了下文所有组织方式的写法。1.2 应力组的构成为什么以 branch 为单位第 2 个认知问题的答案是应力组是送去做应力分析的一个几何单元而这个几何单元的天然边界就是 branch。原因很实际应力分析需要的是连续的几何链从约束点到约束点从设备嘴子到设备嘴子。branch 正好是模型里表达一段连续管路的单位一个应力组可以由多个branch 组成这是为了表达跨分支的连续管路例如穿过几个分支、但构成一条力学路径的管系反过来一个 branch 不应同时属于两个应力组——否则同一段几何会在两份分析模型里出现荷载与位移的对应关系就乱了。由此得到本篇的第一条组织原则应力组的划分本质上是力学路径的划分不是图纸上的分区。1.3 CII 与_A两步转换各自的角色第 3 个认知问题的答案要从谁来读、谁来写两个角度回答文件由谁生成定位CIIPSI 应用由应力组生成CAESAR II 可以识别的中间交换格式承载几何与相关属性_A 文件CAESAR II用户选取 CII 后在 CAESAR II 内转换CAESAR II 的分析模型格式也就是说CII 是出手的格式_A是进分析的格式。PSI 负责把模型翻译成 CIICAESAR II 负责把 CII 接纳成自己的_A。中间这一步不是多余的它把三维设计软件的数据模型与应力分析软件的分析模型解耦了——两边可以各自演进接口只锁在 CII 上。对二次开发的直接含义你的脚本能可靠触及的最远边界就是 CII 文件。再往后_A文件、分析求解、报告文件都在 CAESAR II 侧不属于 E3D 二次开发的范围。1.4 报告与回写原文第三步之后是“Once the stress engineer has finished the analysis; he can create a report file…”同时链路定义里包含 “and from” 的回传。所以完整的闭环是报告文件分析结果的交付物是应力工程师的正式成果回写把几何与相关属性回到支管上原文用 “to and from”即传递是双向的。这里必须把边界说清楚回写的执行者是 PSI 应用而不是你的 PML 脚本。二次开发在这个环节能做的是核对——比较回写前后支管的几何/属性是否按预期变化而不是自己动手改。1.5 链路的本质文件级不是 API 级第 5 个认知问题的答案可以浓缩成一句话这条链路是导出文件 → 外部软件处理 → 结果回来的文件级链路不是我方调用对方接口的 API 级链路。这个判断带来四条边界能做本篇代码覆盖不能做明确回避组织应力组、导出清单、核对命名在 PML/.NET 里调用应力分析求解检查 CII 文件是否生成、是否完整解析/生成_A文件那是 CAESAR II 的格式记录导出前后模型侧的差异直接写分析结果进模型回写由 PSI 完成把核验结果做成交付清单反向从报告文件自动改模型1.6 数据一致性的四个断点一条文件级链路上数据最容易出问题的位置有四个正好对应四个核验点进模型 → 应力组应力组有没有漏掉 branch、有没有重复包含出应力组 → CIICII 文件是否真的生成了、生成时间与模型状态是否对应回分析 → 模型回写前后几何/属性有没有按预期变化名全链路应力组名、CII 文件名、报告文件名三者的对应关系是否可追溯。第 4 条最容易被忽略却是三年后回溯问题时的唯一线索。所以下文会重点给出一份命名约定模板。二 完整代码与逐行剖析2.1 应力组清单表结构应力组管理的第一步是把它变成一张表。推荐字段如下真实项目里逐行填写字段一个都不要省字段说明示例示意非真实项目数据应力组名全链路唯一标识SG-P-1201-A包含分支一个或多个 branch逗号分隔P-1201/B1,P-1201/B2起止点力学路径的两端设备嘴子 N1 → 管架 PH-02温度工况设计/操作温度设计 180℃ / 操作 150℃压力工况设计压力设计 1.6 MPaCII 文件名PSI 生成物SG-P-1201-A.cii_A文件名CAESAR II 转换物SG-P-1201-A_A报告文件名应力工程师交付物SG-P-1201-A-report状态待组织 / 已导出 / 分析中 / 已回写 / 已关闭已导出责任人应力工程师姓名状态字段是这张表的灵魂它让现在卡在哪一步变成一个可查询的字段而不是靠邮件回忆。2.2 用 PML 导出待组织分支清单要把应力组组织干净先得知道自己有哪些 branch 可选。下面这段脚本按 ZONE 列出分支名与类型作为应力组组织阶段的分支候选清单沿用本次调研已确认的集合与属性写法-- -- 文件建议名branManifest.pmlfnc -- 用途列出当前 ZONE 下的 BRAN 候选清单供应力组组织阶段使用 -- 输出BRAN;名称;类型 与汇总行 BRAN-TOTAL;数量 -- 说明按通用 PML 语法构造需在本地 E3D Design 环境验证。 -- 本脚本只读不写库命名法见 2.4 命名约定模板。 -- define function !!branManifest() is REAL !n 0 -- 作用域当前 ZONE 下的全部 BRAN var !b coll all bran for zone do !x value !b $!x -- 把该 BRAN 置为 CE !bn !!ce.name -- 分支名 !bt !!ce.type -- 类型串 !ln BRAN; !bn ; !bt P $!ln -- 结构化输出便于外层转表 !n !n 1 enddo !ln BRAN-TOTAL; !n P $!ln return !n endfunction逐行要点与第 15 篇同源的写法这里只标差异点var !b coll all bran for zone——COLL ALL 类型 FOR 父级BRAN与for zone两种写法都在本次调研确认过的范围内。do !x value !b—— 逐个把元素设为!!CE$!x单独成行是把该元素送进命令解析器。!!ce.name/!!ce.type—— 属性读取社区真实宏中出现过同名属性。P $!ln—— 变量注入打印形式来自官方培训代码的$!Type注入。只输出不筛选—— 筛选交给表格与后续脚本脚本越笨越不容易出错。2.3 CII 导出前后的核验脚本导出前后要核验的东西不同导出前核清单对不对导出后核文件在不在、对不对得上。后者可以完全用文件系统信息完成不需要任何 AVEVA API# verify-psi.ps1 —— 核对应力组 CII 导出结果# 用法把应力组清单表另存为 CSV含 Group, CiiFile, AFile, Report 四列后运行param([Parameter(Mandatory $true)][string]$TableCsv,# 应力组清单 CSV[Parameter(Mandatory $true)][string]$CiiDir,# CII 文件所在目录[string]$MinBytes 1024# 视为可能不完整的字节下限)$rowsImport-Csv-LiteralPath$TableCsv$reportforeach($rin$rows){$ciiJoin-Path$CiiDir$r.CiiFile$existsTest-Path-LiteralPath$cii$sizeif($exists){(Get-Item-LiteralPath$cii).Length}else{0}$stampif($exists){(Get-Item-LiteralPath$cii).LastWriteTime}else{$null}[pscustomobject]{Group$r.GroupCiiExists $existsCiiBytes $sizeCiiTime $stamp# 三个布尔判据不存在 / 体积过小 / 超出 24 小时未更新NeedCheck (-not$exists)-or($size-lt[int]$MinBytes)-or($stamp-and((Get-Date)-$stamp).TotalHours-gt24)}}$report|Format-Table-AutoSize$bad$report|Where-Object{$_.NeedCheck}需要复核的应力组数$($bad.Count)# 把核验结果落盘作为交付证据的一部分$report|Export-Csv-LiteralPath([IO.Path]::ChangeExtension($TableCsv,.verify.csv))-NoTypeInformation-Encoding UTF8三个判据的含义要讲清楚判定标准必须是可量化的判据阈值说明CII 不存在文件缺失应力组建了但从未导出或导出失败体积过小小于设定字节下限文件可能是空壳/被截断下限按本项目实际正常体积的常识值设定超过 24 小时未更新时间差 24h模型改过但 CII 没重导这是最危险的一类不一致第三条尤其重要CII 是模型在某一时刻的快照。模型改了而 CII 没重导等于拿着旧几何在做分析。这条判据用一个时间戳比较就能防住。2.4 命名约定模板命名是全链路的追溯骨架。推荐模板一致性由人工与脚本共同保证应力组名 SG-管线号-序号 例SG-P-1201-A CII 文件 SG-管线号-序号.cii 例SG-P-1201-A.cii _A 文件 SG-管线号-序号_A 例SG-P-1201-A_A 报告文件 SG-管线号-序号-report 例SG-P-1201-A-report四条硬规矩命名里不含空格、不含中文、不含斜杠—— 避免跨工具传递时被转义应力组名与三个文件名同源—— 用前缀就能反查不靠目录约定一个应力组一个序号不复用—— 序号回收会让历史记录失去意义应力组名与 branch 名的对应关系写进清单表—— 不要只存在于人的记忆里。2.5 交付核验清单把 2.1 的表、2.3 的脚本、2.4 的命名合成一张交付前清单#核验项判据责任方1每个应力组至少含 1 个 branch包含分支数 ≥ 1二次开发/设计2同一 branch 未被两个应力组包含重复 branch 数 0二次开发3所有应力组均有 CII 文件缺失数 0二次开发4CII 文件在模型冻结后 24 小时内生成超期数 0二次开发5命名符合模板不合规数 0二次开发6_A与报告文件齐备缺失数 0应力工程师7回写前后差异已记录未记录数 0应力工程师/二次开发8状态字段已更新到已回写/已关闭陈旧状态数 0全链路第 2 项和第 4 项是二次开发最该盯的两项——它们纯靠数据比对就能完成不需要任何应力分析专业知识。三 常见报错与排查现象 1应力组清单建好了CII 文件却迟迟不出现。原因候选应力组的包含分支为空选中的 branch 名与模型实际名不一致或 branch 已被删除/改名。处置回到三维设计侧用 2.2 的脚本重新导出该 ZONE 的 branch 候选清单与表格中的包含分支逐条比对。先确认 branch 存在再谈导出。现象 2CII 文件在 CAESAR II 里选取后转换失败或读不全。原因候选一CII 文件本身不完整导出中断文件被截断——用 2.3 的体积判据先筛一遍原因候选二几何链不连续应力组里包含的分支之间存在未连通的位置力学路径是断的。处置先按文件级判据排除文件问题若文件正常则回到模型侧检查应力组的分支是否构成连续管路这正是应力组按力学路径划分这条原则的由来。现象 3回写之后模型里出现了重名或重复对象。原因候选同一 branch 被两个应力组包含两轮回写各自生成了一套结果。处置用 2.5 清单的第 2 项重复 branch 数 0作为强制门禁在导出前就卡掉。回写是写库操作DABACON 上的写操作不可逆务必在测试 MDB 上先验证系列铁律 8。现象 4应力工程师说它手上那份 CII 和最新模型不一致。原因候选模型改动后没有重新导出 CII。CII 是某一时刻的快照不具备自动同步能力。处置把 2.3 脚本的第三条判据超过 24 小时未更新纳入例行核验模型冻结节点后立即重导并刷新清单表里的时间。现象 5应力组名字和 CII 文件名对不上回溯时找不到对应关系。原因候选命名没有遵守统一模板或中途被人工改名。处置按下节 2.4 的四条硬规矩重建命名并在清单表里保留应力组名 → CII 文件名的显式对应列。命名不一致的代价不会在当下爆发而是在几年后回溯时才爆发。现象 6想用脚本把分析结果直接改进模型发现根本走不通。原因候选链路是文件级、回写由 PSI 应用完成脚本本就没有这个通道。处置接受边界。脚本的正确姿势是核对员而不是执行者核对回写前后差异、核对状态字段、核对文件齐备性。四 动手练习练习 1清单建表判定标准表格字段齐全按 2.1 的字段结构为你熟悉的一条管线建立一张应力组清单表可以是示例数据。判定标准十个字段全部有值或明确标注待填且状态字段使用了给定的五档取值之一。练习 2分支清单判定标准拿到非零计数用 2.2 的脚本导出某个 ZONE 的 branch 候选清单。判定标准BRAN-TOTAL的数值大于 0且输出行的名称与模型中的分支名一致。该脚本需在本地 E3D Design 环境验证。练习 3文件核验判定标准能解释三个判据的触发条件用 2.3 的脚本核验一批 CII 文件可用占位文件测试。判定标准能分别说出文件缺失“体积过小”超期未更新三个判据的触发条件并说明第三条为什么最重要。练习 4命名重构判定标准零不合规按 2.4 的模板为你表格里的每个应力组补全四个名字。判定标准四个名字全部不含空格、中文与斜杠且都能由应力组名加后缀推导出来。练习 5边界自测判定标准各举两例写下这条链路上我的脚本能做/不能做各两条。判定标准能做的两条必须落在读清单、核文件、比差异、出报告之内不能做的两条必须包含调用应力分析求解和直接生成_A文件。五 小结与下一篇预告本篇三句话链路是五步文件级传递应力组 → CII → CAESAR II 的_A→ 报告 → 回写原文的 “to and from”。应力组按力学路径划分最小单位是 branch一个 branch 不进两个组——这条纪律能防住最麻烦的回写重名问题。脚本的定位是核对员能可靠触及的边界是 CII 文件与清单表之外的事交给 PSI 应用与应力工程师。到这里单件的重活都讲完了。但工程项目的现实是这类作业不是做一次而是做几百次——几百个应力组、几百张图纸、几百份报表还要在没人盯着的情况下跑完。第 18 篇《批量化作业与无人值守》就讲这件事三类批量任务出图、报表、校验怎么组织任务清单怎么设计才能重跑一次不出错日志与失败隔离怎么做以及官方 PML Add-in 机制PLOBJ控制文件、UIC 文件、PowerWheel 挂载到底解决了什么问题——顺便讲清官方为什么明确不建议从标签页按钮直接调用 PML 宏。文末 FAQFAQ 1PSI 在哪一层工作是在三维设计软件里还是在 CAESAR II 里PSIPipe Stress Interface是三维设计侧的应用用户在三维设计环境里建应力组PSI 依据应力组生成 CAESAR II CII 格式文件。CAESAR II 一侧的工作是用户选取这个 CII 文件把它转换成本软件的_A格式文件然后进行分析。也就是说PSI 的职责止于把模型翻译成 CII再往后进入 CAESAR II 领域。需要说明的是该原文出自《Pipe Stress Interface User Guide》的第三方托管副本原文语境是 PDMS在 E3D Design 上的实际可用性请以本机安装为准。FAQ 2什么是应力组为什么必须以 branch 为单位应力组是送去应力分析的一个几何单元官方定义为 “consisting of one or more PDMS branches”即由一个或多个 branch构成。以 branch 为单位的根本原因是应力分析需要的是连续的几何链从约束点到约束点而 branch 正是模型中表达一段连续管路的天然单位一个组允许包含多个 branch是为了表达跨分支的连续管系。由此推出一条纪律应力组的划分应按力学路径而不是按图纸分区同时一个 branch 不应同时属于两个应力组否则回写时会出现重名与重复对象。FAQ 3CII 和_A是什么关系为什么中间要转一次CII 是由 PSI 应用从应力组生成的、CAESAR II 可识别的中间交换格式_A是用户在 CAESAR II 中选取该 CII 文件后转换得到的CAESAR II 分析模型格式。中间转一次的意义在于解耦三维设计软件的数据模型与应力分析软件的分析模型各自演进接口只锁在 CII 这一层。对二次开发的含义是脚本能可靠触及的最远边界就是 CII 文件_A文件属于 CAESAR II 的格式不应由你的脚本解析或生成。FAQ 4分析结果怎么回到模型里是脚本写的吗回写的执行者是PSI 应用不是你的脚本。官方原文在描述这条链路时使用了 “transfer the geometry and relevant attributes to and from”说明传递是双向的既要送去做分析也要把结果回传分析完成后应力工程师可以生成报告文件几何与相关属性随后回到支管上。二次开发在这个环节的角色是核对比较回写前后支管的几何与属性是否按预期变化、更新状态字段、记录差异。回写属写库操作DABACON 上不可逆必须先做备份或在测试库上验证。FAQ 5这条链路上二次开发能做什么、不能做什么能做四件事组织应力组并导出分支候选清单核对 CII 文件是否存在、体积是否正常、是否在模型冻结后 24 小时内更新做全链路命名合规检查记录导出与回写前后的差异并输出交付核验清单。不能做三件事在 PML/.NET 里调用应力分析求解解析或生成_A文件绕开 PSI 直接把分析结果写进模型。判断标准很简单——凡是读清单、核文件、比差异、出报告的都在边界内凡是调用对方求解、操作对方格式、代替对方写库的都在边界外。