System architecture

PLM 参考架构与 Cympha 案例研究

2026 年 10 月

一套 PLM，实为两套系统：一套产品模型，要求准确；一套工作流，要求易用. 二者是性质不同的工程问题，按同一套思路设计，必有一方被牺牲.

本文分为两层. 概念层给出两半各自的参考架构，围绕四个要点展开：工作流编排、三类 Agent 构成的执行层、Mesh 与 CAD 两类几何同场、带置信度与策略的变更管理. 实现层随后以 Cympha 为案例研究，展示这套架构已经在运行的形态 —— 一份 103,966 行的参数化目录、五个已投入使用的 Agent 模块，以及一个在浏览器中编辑的参数化装配体.

两套系统：产品模型与工作流

产品模型回答"东西本身是什么"：物料、目录、产品结构、实例、版次、有效性. 这部分数据贯穿产品全生命周期，是其余一切功能的查询基础，也是应当严格遵循业界成熟规范、而不必另创体系的一半.

工作流回答"每一步由谁来做"：任务分派、审批、拆分、变更管控、过程留痕，以及哪些步骤可以交由机器执行. 一套系统最终是被真正使用，还是被人绕开，取决于这一层.

两者缺一不可，但建设方式完全不同. 一个是必须精确的数据模型，另一个是必须让人愿意待在里面的运行环境. 当成一套系统来设计，总有一方被牺牲，而实际中被牺牲的往往是后者：研发团队把真实工作放在任务工具和排期表里，只把正式关口留给 PLM.

工程过程归 PLM，不归 ERP

工程过程属于 PLM：以请求、指令、通知三件套构成的变更管理，生命周期状态与发布关口，项目计划与交付物，需求及其追溯关系 —— 全部落在 PLM 一侧.

ERP 从发布开始. 它依据交到手上的既定清单采购、生产、排程与核算，不关心这份设计是怎么形成的. 如果 PLM 没有把工作流做好，没有第二套系统会接手.

这一点之所以重要，是因为工作流恰恰是 PLM 实施中最常被放弃的一半. 项目模块是有的 —— 排期、任务、交付物、关口 —— 但它们按对象流转的思路建成：擅长回答"谁必须批准这个对象才能进入下一状态"，而对工程师真正要问的"我手上在做什么、哪里卡住了"回答得很差.

四项架构要点

有四点使这套架构区别于常规 PLM 做法. 后文每一节，都是其中之一的展开.

1. 工作流编排 —— 任务、责任人、分包. 引擎调度的是任务与责任人，而不是让对象走一遍状态机. 子任务自带完整上下文与交付物定义，因此派给内部设计师与外发给另一家组织是同一个调用，而不是两套机制.

2. 三类 Agent 构成的执行层 —— 设计、文件处理、AI 模型处理. 三类 Agent 与人共用一份任务契约：认领、加锁、回传、裁定. 新增一类执行者是写一个插件模块，而不是启动一次集成项目.

3. Mesh 与 CAD 是同等的两类表示. 扫描网格与精确边界表示都是一等公民. 表示是几何句柄上的一个属性，而不是数据模型里的分支，因此版次、有效性、反查与权限对两类完全一致.

4. AI 参与的变更管理 —— 置信度与策略. 变更提议对象是工程变更单的超集：它带一个置信度，使机器可以如实提出；带一份策略配置，按组织与变更类型设定自动执行阈值与每日上限.

贯穿这四点的前提是参数化目录即物料主数据. 零件带稳定编号与尺寸参数，参数直接驱动几何生成. 没有稳定编号就没有反查与变更传导；没有参数，剩下的就只是文件.

参考架构

关键性质在最上面两行之间的接缝. 执行者是插件式的，这正是浏览器、CAD 工作站 —— 以及日后某个尚未接入的 CAD 系统 —— 能够在同一套治理下并存的原因. 凡是能接收任务并返回结果的，都可以占据最上面那一行.

产品模型

目录物料、选定变体、已定位的实例 —— 这三者构成机械 PLM 的立身之本. 复用发生在目录层，而不在顶层装配体，这正是按单设计与批量生产可以共用同一套模型的原因.

多层 BOM 不过是一张邻接表加一张闭包表，难点不在这里，而在有效性. 一旦结构关系带上"自某日期、某序列号起生效"，每一次读取就都变成按时点提出的问题，并且贯穿全部查询路径. 这件事在设计之初做进去，远比事后补上便宜.

工作流编排：任务、责任人、分包

传统 PLM 流程把对象在状态之间流转，这套架构流转的是任务与持有人. 每个工作单元都写明此刻由谁持有、以何种角色持有，因此交接是一次有操作人的动作，而不是状态变化的副产物.

由四个部分承载：

• 持有人 —— 当前责任人及其角色，直接写在记录上.
• 状态 —— 一台带守卫条件的状态机，人与机器都必须经过. 关于谁有权做什么的规则，只在这一处生效.
• 任务分解 —— 一个单元拆成若干本身完整的子单元，各有持有人、文件、审批与留痕.
• 过程留痕 —— 只追加的日志，记录操作人、类型与内容，并带可见性标记，决定同一条记录中外部方能看到哪些部分.

递归分解的意义比表面更大. 当子任务是一个完整的工作单元、而不是一行排期时，它自带交付物与评审；并且子单元可以落在另一个组织，于是拆分工作与外发工作成为同一个动作，共用一条审计链. 供应商协同由此不再是独立模块，而是任务分解的自然结果.

任务分派同样由这套模型导出：先按步骤要求的角色能力筛选名单，再按实时负荷择人，持有人若仍合格则保持不变 —— 并在任何人确认之前，先显示每一条可选下一步会流转给谁.

AI 参与的变更管理：置信度与自动执行策略

传统的变更记录是请求、指令、通知三件套. 这里是同一个对象，多了两样东西：一个置信度，使机器可以如实提出；一个策略开关 —— 按组织、按变更类型设定 —— 让组织自行决定哪一类变更无需评审会即可通过，并设每日上限.

一项变更在形状、配合与功能上是否中性，仍由人判定. 系统负责沿产品结构算出影响范围并记录结论，不代替人下判断. 于是同一套机制既服务日常变更传导，也服务正式变更评审，二者的区别只在那个开关上.

三类 Agent，共用同一套任务契约

一个人在审阅模型、一段脚本在授权 CAD 会话中无人值守地运行、一个模型在浏览器中推理 —— 对工作流而言，三者形态完全一致：各自认领任务、在执行期间锁定记录、返回产物与结论，再由策略或由人作出裁定.

这样做的收益是：自动化自上线之日起就处于治理之下 —— 有上限、可审计、可回退 —— 而不是变成一条绕开他人评审流程的旁路. 它同时也是那道接缝：日后某个尚未接入的 CAD 系统，可以作为一个执行者加入，而不必立项做集成.

计算在哪里发生

三个位置，按各自掌握的资源划分.

使之成立的可移植方案：将计算内核从应用程序中剥离，使其可无界面运行，然后编译两次 —— 原生库供服务器与工作站使用，同一份源码编译为 WebAssembly 供浏览器使用. 一个没有界面层、不派生子进程、内存占用有界的内核，本身就已经是 WebAssembly 所要求的形态.

CAD 文件的四个层次：原生、集成、轻量、中性

原生支持来自 CAD 厂商自身接口在授权席位中的运行，没有人从外部去解析文件格式. 派生出的轻量化模型承载了绝大部分访问量，供非 CAD 用户查阅设计数据 —— 这也是浏览器无需接触精确几何的原因. 由此产生一项值得点明的义务：每一份轻量化模型都必须可追溯到它所依据的版次，并随版次变化重新生成，否则它会悄悄过期.

Mesh 与 CAD：两类表示，同一产品结构

真实装配体同时包含两类件. 目录件由供应商以精确边界表示提供，带参数、带编号、可反查；现场件来自扫描或由算法生成，是三角网格，没有特征树，也没有父模型. 多数 PLM 只把其中一类当作一等公民，另一类退化为附件 —— 另一半数据因此永远留在系统之外.

网格几何（STL、OBJ、PLY）是一次性的，不带参数，需要的是修复、自交消解、布尔运算、简化与配准. CAD 几何（STEP、IGES、BREP）带装配树、位姿、零件名与尺寸参数，需要的是按视图弦高三角化、结构提取与版次比对.

架构上的处理是：表示是属性，不是分支. 产品结构挂的是实例，实例持有一个几何句柄，而该句柄解析为网格还是边界表示，只是它上面的一个属性. 版次、有效性、反查与权限对两类完全一致，不存在"CAD 走流程、网格走附件"这样的二等通道.

分叉只发生在算子层. 同一个"测量"任务，对网格走最近点距离场，对边界表示走精确面求值；同一个"显示"任务，网格直接送显，边界表示先三角化. 任务类型并未改变 —— 执行者按表示挑选实现，这正是 Agent 采用插件式的理由. 两类几何还必须能在同一场景中共存并相互测量，因为装配约束、间隙校核与干涉检查都跨表示发生，而不是各自为政.

第二部分 —— 实现层：Cympha 案例研究

一个文件存入云端、在 Studio 中打开、由代理处理、在主应用中获批 —— 自始至终是同一个对象. 每个界面都可以单独采用；合在一起，则闭合了从受理到交付的完整回路.

对照 PLM 的各项功能模块，组件是一一对应的，而且每一行点名的都是正在运行的机制，不是计划中的.

已经建成的部分

零部件库. ImplantCatalog.xml 共 103,966 行，随产品一同发布. 库与其中的目录各自带版本属性，树状结构从制造商到系列再到零件，每个零件都有方案直接引用的固定编号，而平台直径、直径、长度、根端直径、实际长度这些尺寸是驱动几何生成的，不只是标注. 参数化目录通常是 PLM 项目中必须从零建设、投入最大的一块；在这里它是设计引擎的运行前提，数年前即已建成，并由商业团队持续维护.

任务编排. 分派先按步骤声明的角色筛选名单，再在其中挑出手上未结事项最少的人 —— 实时统计，并以固定规则处理并列. 仍然合格的持有人保持不变. 并且在任何人操作之前，界面就显示每一条可选下一步会流转给谁 —— 由实际执行分派的同一个函数算出，这是刻意为之：预测到的承接人与真实承接人不一致，会摧毁对整套机制的信任.

浏览器承担实际作业. 可视化客户端浏览模型树，逐件附上目录规格；在 Worker 中计算面到面的距离场；批注并输出报告；并通过一条与桌面例程逐步对齐的八步流程修复几何，因此同一模型在浏览器与工作站上修复，结果一致. 其中的方案编辑本质上是参数化：选择目录零件，设定直径、长度与深度，确定实例位置，配合件随之更新，最后写回桌面应用程序读取的同一份工程文件. 配置环节由此完全脱离 CAD 席位.

推理在客户端运行. 目标检测、交互式分割、特征点识别与测量追迹，全部在使用者本机执行. 没有推理服务器，没有 GPU 集群 —— 而对工程数据而言最要紧的一条是：图像不离开本机.

WebAssembly，已有两例. 桌面产品自有的精确几何内核被编译为 WebAssembly，采用精确谓词内核，并以头文件实现的高精度算术替换原有依赖. 第二个模块是分析内核，带显式的内存布局版本号，并以类型化视图访问线性内存、随堆增长自动刷新. 两者遵循同一条路径：取出计算内核，剥离界面，给它一个扁平的数据接口，然后编译两次.

三类 Agent，五个模块. 工作站上的 Agent 宿主实现一个插件接口，目前有五个模块在其上运行. AlignerBot 是完整形态的设计 Agent —— 整条设计链无人值守地跑完，而不是辅助其中一步，设计师只做收尾审阅. 体数据分割是 AI 模型处理 Agent：CBCT 流水线，其模型资产独立于宿主单独版本化与分发，因此模型升级不等于重装. 其余三个属于文件处理：监视文件夹导入在设备与扫描仪输出出现时即取走，选择并上传让浏览器会话挑选本机文件并通过直连存储传输建立病例，云端动态监视则是其余模块认领任务与回传结果所共用的那条通道. 把数据送进系统本身就是 PLM 中最被低估的问题，五个模块里有三个是为它而存在的.

取例：一个装配体，从目录到交付

一个装配体，从头走到尾. 手术导板是为单一工件制作的夹具 —— 这个类比是严格的，不需要任何行业知识就能被机械领域的读者理解：目录件按参数定位，再由一个贴合既定基准生成的本体把它们固定住.

同一组参数驱动两件不同的事：直径、长度与深度决定选用哪一个目录件，角度与位姿决定它装在何处. 而且这些放置是受约束的，不是自由摆放：套管与其种植体同轴，并按系统规定的高度偏置 —— 这是一条装配配合关系，而且已经在执行.

把它读作一张物料清单，对应关系是机械的：

这里的设计 BOM 与生产 BOM 确有区别 —— 交付出去的是打印本体，加上待压装的外购套管、固位钉与钻孔方案 —— 而产品规模又小到可以一眼看全.

它还为变更机制提供了一个有后果的检验场景. 制造商修订了一款套管：在制的哪些装配体含有它？已交付的哪些是按旧几何制作的？这正是反查与有效性，而且被放在一个答错有实际后果的问题上检验，依托的是已经在跑的业务 —— 无需先接入第二个行业.

接入更多 CAD 系统

对于一个尚未接入的 CAD 系统，三个问题决定全部工作形态：

1. 能否无人值守运行？有无可在无人操作时执行的编程接口，决定了它能否成为执行者. 若有，它就是又一个代理模块，其余问题皆由此而定.
2. 能否导出轻量化模型？只要能在自身授权会话内写出任一三角网格格式，即可直接供给浏览器层，无需购买第三方转换器授权.
3. 能否交出产品结构？若能返回带位姿的装配树，产品模型便由设计工具直接供给，而不必重新录入 —— 这正是集成的全部价值.

三条皆可，工作量就是在一份已有五个实现的接口上再加一个模块，而不是启动一个集成项目. 无论该系统是新研制、收购而来，还是被重新恢复开发，这三个问题同样适用.

对于既有的主流 CAD，有两条路径，多数部署两条都要. 经由席位：代理模块在授权会话内部，通过厂商自身接口运行程序 —— 完整保真、真实的装配树、无需转换器授权，但需要席位，并需跟随该产品的版本更新. 服务端解析：一个成熟的开源几何内核读取中性交换格式，经其数据交换层返回带名称与颜色的装配树，完成三角网格化并输出轻量化模型 —— 无需席位、无授权争用，并可处理供应商来件、归档与批量迁移. 当必须在没有席位的情况下读取原生格式时，商业转换器是这条路径的付费增强.

后续路径

依赖顺序本身就是论据. 每一步都让后一步更省力，而没有哪一步需要先相信后一步会成立 —— 这使整个序列可以安全启动. 其中前两步即可用生产环境中的业务数据验证整个产品模型，无需接入第二个行业.

有一处是刻意留白的：进度分成两件事. 依赖关系是数据，写入模型；先后次序是调度，由编排层在运行时按就绪状态与产能决定，而交期则来自实测的周期时间，不靠事先排定的计划.