企业官网建设流程全解析

版本声明

• 本篇基线为AVEVA E3D Design 3.1。
• 官方术语统一写作设计规则检查（design rule-checking），首次出现使用全称。
• 官方原文引用来源为 E3D Design 数据手册 PDF 与官方帮助《Automatic Pipe Route Administration》章节（PDUV14.5.2）。
• 重要事实交代：本次调研未找到官方公开的"默认规则清单"，也未找到 E3D “Design Rule Check” 的独立官方配置手册页 URL。因此本篇只讲"如何写自己的规则"，不列举、不臆造任何官方默认规则条目。
• 就规则对象的 PML 写法而言，官方给出的示例只包含对象名与成员/方法名（MINOLOGICAL、.CEREF、.RULEMETHOD()）；本篇的自建规则对象按同一形态构造，属"需在本地 E3D Design 环境验证"。
• 命中条数、元件数量等数值一律为示意，真实值须在本机跑出。

一句话结论：官方承诺的是"规则可以改"，不是"规则内容已公开"；所以设计规则检查这条路上，二次开发人员真正要做的事，是把公司标准翻译成一个可枚举、可定位、可度量、可复跑的自建规则对象，而不是去猜官方默认规则里写了什么。

〇 认知问题

1. 官方数据手册里那句"可配置设计规则检查"到底承诺了什么？它承诺的是规则可改，还是规则内容已经公开？
2. 既然官方说"可以扩展或修改标准部署中的默认规则"，那为什么我在官方文档里找不到一份默认规则清单？
3. 官方帮助里那个出现在自动配管规则中的 PML 对象长什么样？它的规则方法是靠什么被调用的？
4. 我自己写的规则检查，和系统里的 Data Check、Data Consistency、Clashes 是同一件事吗？该用哪个、什么时候用？
5. 规则检查跑完输出一大堆命中，怎么才能让它真正"接进交付流程"，而不是变成没人看的日志？

一 机制解析

1.1 官方原文，以及它真正的含义

AVEVA E3D Design 数据手册对设计规则检查的原文是：

“Configurable design rule-checking enables users to extend or modify the default rules provided in the standard AVEVA E3D Design deployment, ensuring projects are meeting company or client-specific standards”

（来源：https://www.aveva.com/content/dam/aveva/documents/perspectives/datasheets/Datasheet_E3DDesign.pdf）

这句话里有三个关键信息点，值得逐字拆：

1. “Configurable”—— 前提是"可配置"。也就是说，规则不是硬编码在某处不可改，而是留了扩展与修改的口子。
2. “extend or modify the default rules provided in the standard deployment”—— 官方承认标准部署里存在默认规则，并且这些默认规则可以被扩展或修改。
3. “ensuring projects are meeting company or client-specific standards”—— 目的非常明确：让项目满足公司或客户的特定标准。公司标准往往比行业通用标准更严，这才是规则检查的真正战场。

但请特别注意：这句话只承诺"默认规则存在且可改"，它没有承诺"默认规则的内容会被公开成一份清单"。这就是第 1 与第 2 个认知问题的答案所在。本次调研在官方公开渠道（帮助站、数据手册、发布说明）中未找到可下载或可查阅的默认规则清单，也未找到“Design Rule Check” 的独立配置手册页 URL。于是我们面临一个必须如实说明的处境：

默认规则里的条目是什么，公开资料里没有。所以任何"官方默认规则有 XX 条、分别检查 XX"的写法，都是编造。

本篇的做法是：承认这个空白，把方法论写足——凡是公司标准能说清的，都能写成自建规则；凡是官方默认规则覆盖的部分，实际项目中以本机运行时的实际表现为准。

1.2 官方给出的 PML 规则形态

官方帮助《Automatic Pipe Route Administration》章节（https://help.aveva.com/AVEVA_Everything3D/3.1/PDUV/PDUV14.5.2.html）给出了在自动配管规则中调用 PML 对象的真实示例，其形态包含三件东西：

这三件东西就是"规则对象"的最小骨架。它和我们前面学过的 PML2 对象技术完全同源：

• define object <类型名>与member .<名> is <类型>的写法，与官方培训材料里的define object GETELEMENTINFORMATION/member .element is DBREF/member .name is STRING/member .position is POSITION是同一种语法；
• define method .<名>()的写法与表单示例里的define method .print()是同一种语法；
• 成员访问一律点号，!this指向对象自身（官方示例里!this.element = !!ce、!this.name = !!ce.name）。

所以"写一条自己的设计规则"在技术上等于"写一个带规则方法的 PML2 对象"。门槛比你想象的低。

1.3 未找到默认规则清单，意味着什么（写作纪律）

对写作者与开发者而言，这个空白意味着三条纪律：

1. 不要伪造清单。任何"默认规则一览表"只要没有官方出处，就是假信息。
2. 不要用"官方规则里已经有这条"来给自己的规则背书。你的规则是你的规则，就写清楚它是自建的。
3. 要把"规则的可表达范围"讲透。既然条目未公开，读者能带走的就只能是"怎么写规则"这项能力——这才是本篇要交付的东西。

1.4 三层防线：规则检查、数据检查、碰撞检查不是一回事

E3D 的通用功能里另有几类校验手段（官方"Common Functionality"侧的能力）：

这三者的分工可以记成一句话：

规则检查管"符不符合公司标准"，数据检查管"数据自己有没有坏"，碰撞检查管"东西有没有撞上"。

第 4 个认知问题的答案是：它们不是同一件事，也不互相替代。自建规则对象补的是第一格——因为只有它才能表达"公司特有约定"。而 Clashes 的结果可以 Save to Excel，这给了我们一个很好的落点：把自建规则命中结果也做成同构的表格，让质控人员在一个流程里看完两类结果。

1.5 自建规则对象的四个设计要点

一条规则能不能用，取决于它是否同时满足四条：

1. 可枚举—— 规则的作用域能用集合表达（“哪些分支”“哪些区域”），而不是"我看看这个分支"。
2. 可定位—— 命中时能立刻回到具体元素（靠.CEREF保留 DBREF，而不是只打印一句话）。
3. 可度量—— 判定结果是离散的（PASS / FAIL / NA），而不是"看起来不太对"。
4. 可复跑—— 同一条规则在任何时间、任何机器上跑，对同一份数据给同一结论（幂等）。

这四条也是后文代码的组织原则：

• 第 1 条 → 用COLL ALL … FOR …组织作用域；
• 第 2 条 → 对象里必有member .CEREF is DBREF（这也是官方示例的写法）；
• 第 3 条 → 对象里再加member .RESULT is STRING与member .HITS is REAL；
• 第 4 条 → 规则方法里只读不写（呼应第 15 篇的结论：核对而不是改写）。

二 完整代码与逐行剖析

2.1 规则对象的形态约定

本篇所有规则对象统一遵守三个成员约定（在官方MINOLOGICAL形态基础上扩充）：

方法入口统一叫.RULEMETHOD()（沿用官方示例方法名）。

2.2 一条具体规则：BRAN 下必须有支吊架

选这条规则做示范，理由有二：一是它在工程上非常真实（支架缺失是施工阶段最常见的返工原因之一）；二是它只用到本次调研已确认的元素类型串，不涉及任何臆造类型名。

-- ============================================================ -- 文件建议名：RULEBRANSUPPO.pmlobj -- 规则语义：指定 BRANCH（BRAN）下必须至少存在一个支吊架（SUPPO） -- 形态来源：官方《Automatic Pipe Route Administration》中 -- define object / member .CEREF is DBREF / define method .RULEMETHOD() -- 说明：按官方示例形态构造，需在本地 E3D Design 环境验证。 -- 规则只读不写；命中结果以分号分隔行输出，便于外部转表。 -- ============================================================ define object RULEBRANSUPPO member .CEREF is DBREF -- 规则作用的当前元素，沿用官方成员名 member .RESULT is STRING -- 判定结果：PASS / FAIL / NA member .DETAIL is STRING -- 判定依据（人可读） member .HITS is REAL -- 命中计数：FAIL 记 1，其余记 0 endobject define method .RULEMETHOD() !this.CEREF = !!ce -- 把当前元素记进对象，便于事后定位 !this.RESULT = 'NA' -- 先给安全默认值，避免"未赋值"混杂 !this.HITS = 0 !this.DETAIL = '' !t = !!ce.type -- 读当前元素类型串 if (!t ne 'BRAN') then -- 作用域不匹配：不算失败，也不算通过，明确标为 NA !this.RESULT = 'NA' !this.DETAIL = 'CE-is-not-BRAN' else -- 只读核对：把该 BRAN 下的支吊架收进集合 var !sup coll all suppo for CE !n = !sup.size() -- 集合元素个数 if (!n eq 0) then !this.RESULT = 'FAIL' !this.HITS = 1 !this.DETAIL = 'no-support;branch=' + !!ce.name else !this.RESULT = 'PASS' !this.HITS = 0 !this.DETAIL = 'supports=' + !n endif endif -- 结构化输出：RUL;<结果>;<依据> !ln = 'RUL;' + !this.RESULT + ';' + !this.DETAIL P $!ln endmethod

2.3 逐行剖析

define object RULEBRANSUPPO … endobject
PML2 的对象定义。官方培训材料中define object GETELEMENTINFORMATION的同款写法。对象类型名建议用大写下划线风格，与官方示例的MINOLOGICAL、GETELEMENTINFORMATION保持一致。

member .CEREF is DBREF
成员类型是DBREF——这条非常关键：只有用DBREF保存引用，命中之后才能"回到那个元素"。若改用字符串保存名字，元素被改名后规则报告就失效了。

define method .RULEMETHOD() … endmethod
官方的规则入口方法名。表单示例里define method .print()以endmethod结尾，本篇统一用endmethod。

!this.CEREF = !!ce
!this指对象自身，点号访问成员。官方示例里的!this.element = !!ce是完全相同的语义。

!t = !!ce.type与!t ne 'BRAN'
!!ce.type读类型串；ne/eq是 PML 的比较运算符，官方控制逻辑示例中出现过IF (!Type eq 'BRAN') THEN。BRAN是本次调研已确认可用的元素类型串。

var !sup coll all suppo for CE
VAR … COLL ALL … FOR …的集合写法，与 AVEVA Community 真实宏var !supp coll all suppo for CE完全一致（这里连变量名都沿用了，因为它确实贴切）。

!n = !sup.size()
集合的.size()方法，社区宏里出现过do !i from 1 to !b.size()。

if (!n eq 0) … else … endif
嵌套 IF。官方控制逻辑示例给出了 IF / ELSEIF / ELSE / ENDIF 的完整形态。这里用嵌套而不是AND组合条件，一是可读，二是避免不同版本对复合布尔表达式的解析差异。

'no-support;branch=' + !!ce.name
字符串拼接用+（社区宏里!c[1] + '-' + !c[2] + '-' + '$!e'是同款）。把元素名带进 DETAIL，是因为这条规则的报告必须可定位。

P $!ln
把拼好的行注入P命令打印。$!var的注入形式来自官方培训代码P CE is $!Type, Pls select Branch.。

为什么不做return？
官方示例的规则方法没有给返回值。判定结果通过对象成员暴露，调用方读!rule.RESULT即可——这比靠返回值更耐用，因为后续可以往对象里加成员而不用改调用方。

2.4 规则驱动循环：把规则套到一批分支上

单条规则只对一个元素有效，要用起来必须有一个驱动循环。

-- ============================================================ -- 文件建议名：runBranSupportRule.pmlfnc -- 用途：对一个 ZONE 下的所有 BRAN 逐条跑支吊架规则 -- 输出：每条元素一行 RUL;... ，末尾一行 RUL-SUMMARY;<FAIL数> -- 说明：按通用 PML 语法构造，需在本地 E3D Design 环境验证。 -- ============================================================ define function !!runBranSupportRule() is REAL !fails = 0 !total = 0 -- 作用域：当前 ZONE 下的全部 BRAN var !b coll all bran for zone do !x value !b $!x -- 把该 BRAN 置为 CE !total = !total + 1 !rule = object RULEBRANSUPPO() -- 每元素一个新规则对象实例 !rule.RULEMETHOD() -- 调用规则入口 if (!rule.RESULT eq 'FAIL') then !fails = !fails + 1 endif enddo -- 汇总行：让外层脚本一眼拿到通过率 !ln = 'RUL-SUMMARY;' + !total + ';' + !fails P $!ln return !fails endfunction

逐点说明：

• var !b coll all bran for zone——for zone的作用域写法取自社区真实宏（如… with matchw(name of suppo,'*copy-of-*') for zone）。
• !rule = object RULEBRANSUPPO()—— PML2 对象的实例化形态，与官方!dim = object measure('mass')的object <类型>()形状一致。
• !rule.RULEMETHOD()—— 方法调用用点号，官方自省演示里的!exampleObject.methods()是同款。
• 每个元素一个新实例—— 避免状态残留（这也是"可复跑"要求的实现细节）。
• 只输出FAIL计数—— 判定结果离散化之后，用一行汇总就能驱动门禁（见 2.5）。

2.5 结果输出与交付门禁

清单行统一成下表格式，质控人员可直接转 Excel；FAIL列的条数就是门禁判据。

门禁建议分三档（判定标准都是可量化的）：

把规则结果做成同构表格的另一个好处是：它可以和碰撞检查的结果（Clashes 支持 Save to Excel）并排放在同一份质控报告里，质控人员不必在两个界面之间来回切。

三 常见报错与排查

现象 1：规则对象定义好了，!rule.RULEMETHOD()却提示方法不存在。

• 原因候选一：方法名大小写或拼写与定义不一致（PML 标识符大小写敏感）。
• 原因候选二：对象定义写在了.pmlobj文件里，而该文件所在目录不在PMLLIB搜索路径中，导致类型根本没被载入。
• 处置：先在 Command Window 里直接手敲define object与define method，确认方法可调用；再把同样内容落到文件，检查PMLLIB。

现象 2：规则跑完一条命中都没有，但人工看模型确实有问题。

• 原因候选一：作用域为空。for zone依赖当前 ZONE 上下文，若 CE 不在任何 ZONE 下，集合为空，循环体一次都不执行。
• 原因候选二：!t ne 'BRAN'的类型串与实际不符，所有元素都被判成NA（NA不计入FAIL，所以表现为"零命中"）。
• 处置：看汇总行的总数。总数是 0 → 作用域问题；总数正常但全是NA→ 类型串问题。

现象 3：规则执行到一半，后面的元素全没了输出。

• 原因候选：PML 的错误机制——宏/函数中的错误不会立即报错，报不报取决于下一行输入；若下一条是匹配的handle命令，错误不输出而转入 handle 块。没有 handle 时，错误可能在后面才浮现，甚至被后续输出淹没。
• 处置：把循环体拆小（一个元素一次调用），在关键步骤前后各插一行P $!ln作为"心跳"，用最后出现的心跳定位中断点。注意：handle块的编号与匹配写法本次调研未取得，本篇不给出具体写法，请以官方《Errors and Error Handling》章节（PMLCUP/PMLCG）的原文并通过本机验证为准。

现象 4：自建规则的命中结果和 Data Check 的结果对不上。

• 原因候选：两者口径不同。自建规则查"公司标准"（例如支架是否存在），Data Check 查"数据自洽"（例如引用是否悬空）。同一元素可以"数据自洽但不符合公司标准"，反之亦然。
• 处置：不要把两者互相当作对方的校验；在报告里分区呈现，并各自注明判据来源。

现象 5：在错误的模块上下文里跑规则，结果全空。

• 原因候选：E3D 各模块（设计、出图、元件库等）的数据上下文不同；在出图模块里遍历模型分支，自然取不到设计数据。
• 处置：明确规则应该跑在哪个模块上下文；把"当前模块"打印进汇总行，作为运行记录的固定字段。

现象 6：规则明明只读，却提示需要写权限。

• 原因候选：规则对象里混进了写操作（例如为方便而"顺手更新一下属性"），或者运行环境自带的锁定机制在工作。
• 处置：坚持"规则方法内只读不写"。一旦破了这条，规则就从"质控工具"变成"批改工具"，风险等级完全不同。

四 动手练习

练习 1（形态复刻，判定标准：方法可被调用）
在 Command Window 里手敲 2.2 的对象定义与方法定义，选中一个 BRAN 后调用.RULEMETHOD()。判定标准：出现RUL;开头的输出行，且结果值为PASS、FAIL、NA三者之一。该写法需在本地 E3D Design 环境验证。

练习 2（作用域验证，判定标准：能解释三个数）
用 2.4 的驱动函数跑一个 ZONE，记录三个数：总数、FAIL数、NA数。判定标准：三个数都给得出，且能说明"为什么NA不计入失败"。

练习 3（写第二条规则，判定标准：规则可枚举、可定位、可度量、可复跑）
自选一条公司标准，写成第二条规则对象（例如"某类分支下元件数量必须大于 1"）。判定标准：四条设计要点逐条自查通过——作用域用集合表达、命中带元素名、结果为三分法、连续跑两次结果完全一致。

练习 4（结果接流程，判定标准：给出三档门禁判据）
把 2.5 的门禁表套到你自己的项目场景上，为三档各写出一条具体判据。判定标准：三条判据都能用"大于/等于某个数"的形式表达，不允许出现"视情况而定"。

练习 5（诚实性练习，判定标准：写出一段可核查的说明）
为你的规则集写一段 README 文字，说明"这些规则是自建的，不是官方默认规则；官方默认规则的条目未在公开资料中找到"。判定标准：文字中存在这一区分，且没有任何关于官方默认规则条目的断言。

五 小结与下一篇预告

本篇的三句话：

1. 官方承诺的是"可配置"，不是"已公开"——默认规则清单未在公开资料中找到，所以不要编造，把方法论写足。
2. 写规则 = 写一个带.RULEMETHOD()的 PML2 对象，形态沿用官方示例的define object+member .CEREF is DBREF+define method .RULEMETHOD()。
3. 规则方法只读不写，结果三分法离散化，再用一行汇总驱动三档门禁，规则检查才能真正"接进流程"。

规则检查把模型质量管住了，但还有一类质量问题不在模型内部——管道会不会因为热胀冷缩把设备顶坏。这件事要靠应力分析，而应力分析软件用的不是你模型里的对象，是文件。

第 17 篇《应力分析对接 PSI 与 CII》就讲这条链路：官方 PSI（Pipe Stress Interface）应用如何把 PDMS 的 branch 组织成"应力组"、如何导出 CII 中间文件、CAESAR II 如何把它转成_A文件，以及分析完成后报告与回写是怎么走完的。读完之后你会明白，这条链路上二次开发的着力点，其实在"把应力组组织干净"，而不是"调用应力分析的 API"。

文末 FAQ

FAQ 1：官方那句"可配置设计规则检查"到底承诺了什么？
它承诺的是三件事：规则在前提出上"可配置"；标准部署中存在默认规则，并且这些默认规则可以被扩展或修改；这样做的目的是让项目满足公司或客户特定标准。它没有承诺默认规则的内容会被公开成清单。原文出自 AVEVA E3D Design 数据手册。

FAQ 2：为什么在官方文档里找不到一份默认规则清单？
因为在本次调研覆盖的官方公开渠道（产品页、数据手册、发布说明、帮助站）中，确实未找到可查阅或可下载的默认规则清单，也未找到E3D “Design Rule Check” 的独立官方配置手册页 URL。事实就是"官方知道这些规则存在、可改，但清单不在公开资料里"。所以正确做法是：不列举、不猜测官方条目，改为把"如何写自己的规则"讲清楚；实际项目中官方默认规则的实际表现，以本机运行的观察为准。

FAQ 3：官方的 PML 规则对象长什么样？规则方法靠什么被调用？
官方帮助《Automatic Pipe Route Administration》给出的示例形态包含三件东西：define object MINOLOGICAL（规则对象类型）、member .CEREF is DBREF（规则作用的当前元素引用）、define method .RULEMETHOD()（规则判定入口）。这套写法与 PML2 的对象/方法语法完全同源：成员访问用点号、!this指对象自身、方法调用写成!obj.方法名()。也就是说，写一条规则在技术上就是写一个带规则方法的 PML2 对象。

FAQ 4：自建规则检查和 Data Check、Clashes 有什么区别？该用哪个？
三者分工不同：自建规则检查管"符不符合公司标准"，因为只有自建规则才能表达公司特有约定；Data Check / Data Consistency / Data Checker 管"数据自己是否自洽"，属系统级完整性校验；Clashes 管"几何是否干涉"，其结果支持 Print Preview 与 Save to Excel。它们不互相替代。推荐做法是自建规则与碰撞检查并行跑，把两类结果做成同构表格放进同一份质控报告。

FAQ 5：规则命中一大堆，怎么让它真正发挥作用？
两步。第一步，把判定离散成三分法并结构化输出：PASS/FAIL/NA，NA表示作用域不匹配、不计入失败；每行都要带元素名或计数，保证"可定位"。第二步，用汇总行的失败计数驱动三档门禁：设计过程中只记录（提示档），专业会签前对关键区域发警告（警告档），交付前失败数大于零即拒绝进入流程（阻断档）。判据全部用"大于/等于某个数"表达，门禁才可执行；同时必须坚持规则方法只读不写，规则才是质控工具而不是批改工具。