2. Windchill产品体系与版本演进

Windchill并不是一个单一软件,而是一套围绕产品数据与流程协同构建的模块化产品体系。理解这套体系的关键,是先分清“平台底座”和“业务模块”两个层次:平台底座提供对象模型、生命周期引擎、权限体系、工作流引擎、数据库与文件存储等公共能力;业务模块则在这些公共能力之上,面向不同角色和场景提供具体功能。选型时如果只比较模块名称,很容易忽略模块之间的数据依赖关系,导致实施阶段出现“功能买了但数据接不上”的问题。

核心模块的功能边界

Windchill PDMLink是整个体系的中心。它管理产品结构(BOM)、CAD文档与图档、零部件主数据、版本与版次、生命周期状态、变更流程(ECR/ECN)以及与CAD工具的集成。可以把它理解为“产品数据的唯一权威源”:任何模块中的物料、图纸、BOM,最终都要回到PDMLink中形成受控版本。判断一个需求是否属于PDMLink,可以问一句:它是否在管理“产品本身是什么、由什么组成、处于什么状态”。

ProjectLink面向项目与项目群管理,管理的是任务、进度、交付物、资源与项目文档。它与PDMLink的边界在于:ProjectLink管“项目怎么推进”,PDMLink管“产品数据是什么”。两者通过交付物关联,例如项目任务可以引用PDMLink中的某个文档或BOM版本作为交付成果,但项目进度状态不会写回零部件的生命周期状态。

PartsLink是零部件分类与复用模块。它通过分类树、属性模板和参数化检索,让工程师快速找到可复用的既有零件,减少“一物多码”。PartsLink不产生新的版本控制逻辑,它依赖PDMLink中的零部件主数据,本质上是给这些数据加上一层可检索的分类视图。实施中常见的误区是把分类属性直接当成BOM属性使用,结果导致同一零件在不同分类下属性冲突。

MPMLink面向制造过程管理,管理工艺路线、工序、工步、制造BOM(mBOM)以及工厂与资源信息。它与PDMLink的关系是“下游派生”:从设计BOM(eBOM)转换或关联生成mBOM,并保持可追溯的映射关系。当设计发生变更时,MPMLink需要判断哪些工序受影响,这是制造与设计协同的核心难点。

Windchill 产品体系:平台底座与业务模块的数据依赖关系 Windchill 平台底座 对象模型 · 生命周期引擎 · 工作流引擎 · 权限体系 · 数据库与文件存储 · CAD集成框架 所有业务模块共享同一套数据模型与流程引擎,模块之间通过对象引用而非数据复制协同 PDMLink 产品数据核心 BOM / 零部件主数据 CAD文档 / 图档版本 生命周期 / 变更流程 ProjectLink 项目协同 任务 / 进度 / 资源 项目交付物 项目文档库 PartsLink 分类与复用 分类树 / 属性模板 参数化检索 零部件复用视图 MPMLink 制造过程管理 工艺路线 / 工序 mBOM / 工厂资源 eBOM→mBOM映射 交付物 分类 派生 版本演进路径与选型判断 Windchill 11.x 传统本地部署为主 模块边界相对独立 Windchill 12.x 支持容器化部署 REST API 能力增强 Windchill+ SaaS 订阅模式 持续更新 / 低运维 选型依据 数据主权 IT能力 / 合规

版本演进与升级路径

Windchill的版本演进大致经历了三个阶段。Windchill 11.x以传统本地部署为主,模块之间的集成更多依赖定制开发,升级周期长、停机窗口大。Windchill 12.x开始强化容器化部署能力,REST API覆盖范围扩大,模块间通过标准接口协同的比例提高,升级方式从“整体停机升级”逐步转向“滚动升级”。Windchill+则是SaaS订阅模式,由PTC托管运行环境,客户按订阅使用,版本持续更新,企业侧运维压力显著降低,但数据主权和深度定制空间受到约束。

升级路径不是简单的版本号替换。从11.x升到12.x,通常需要先做自定义代码的兼容性评估,重点检查三类内容:一是基于旧API开发的定制功能是否被废弃;二是工作流模板中引用的对象类型是否发生变化;三是数据库层面是否存在不再支持的索引或视图。一个可参考的评估顺序是:先盘点定制点清单,再在测试环境执行升级预检工具,最后按“平台→PDMLink→其他模块”的顺序逐层验证。升级预检工具会输出不兼容项报告,报告中标记为“阻塞”的条目必须在正式升级前解决。

选型依据与判断逻辑

模块选型的核心不是“功能多不多”,而是“数据在哪里产生、在哪里被消费”。如果企业的核心诉求是管理设计数据和变更,PDMLink是必选项;如果同时存在多项目并行、需要跟踪交付物与进度,则叠加ProjectLink;如果零部件种类多、复用率低、一物多码严重,PartsLink的优先级会上升;如果设计与制造分属不同部门、需要工艺路线与mBOM管理,MPMLink才具备实施价值。

部署模式的选择则取决于三个约束条件:数据主权要求、IT运维能力和合规要求。涉及军工、航空航天等对数据出境有严格限制的行业,通常选择本地部署或私有云;IT团队规模有限、希望降低运维投入的企业,可以评估Windchill+;介于两者之间的企业,可以选择12.x的容器化部署,在可控性与运维效率之间取得平衡。

选型时建议先画一张“数据产生—消费”矩阵:横轴列出PDMLink、ProjectLink、PartsLink、MPMLink,纵轴列出企业实际业务对象(如图纸、BOM、项目任务、工艺路线)。矩阵中每个交叉点标注“产生”“消费”或“不涉及”。如果某个模块在矩阵中只有“消费”没有“产生”,说明它依赖上游数据质量,实施前必须先治理上游数据。

实施中的常见边界问题

模块边界模糊最常出现在两个位置。第一是ProjectLink与PDMLink的交付物关联:项目任务完成时,交付物应该引用PDMLink中已发布的文档版本,而不是在ProjectLink中重新上传一份副本,否则会出现“项目里是A版、PDMLink里是B版”的数据不一致。第二是PartsLink分类属性与PDMLink零部件属性的关系:分类属性用于检索和复用,零部件属性用于BOM和变更控制,两者可以映射但不应混用。实施时应在数据模型层面明确哪些属性由分类模板维护、哪些由零部件类型维护,避免同一字段在两个模块中重复定义。

MPMLink与PDMLink的eBOM→mBOM映射是另一个需要提前设计的边界。映射关系不是简单的“复制BOM”,而是需要定义哪些设计件对应哪些制造件、哪些工序消耗哪些物料。如果企业在实施MPMLink之前没有梳理清楚eBOM的层级结构和零部件编码规则,mBOM的构建会变成大量手工调整,失去模块化实施的意义。