透过 MBDVidia for MBE 了解如何引领研发设计、工艺制造及质量检测在同一数字线程上共筑 MBE
────────────────────────────────────────
摘 要
────────────────────────────────────────
模型基企业(Model-Based Enterprise, MBE)已成为高端制造业摆脱"图纸时代"路径依赖、走向数据驱动型协同的主流方向。研究表明,超过 85% 的制造企业已经在五项核心 MBE 能力(模型基系统工程 MBSE、模型基定义 MBD、模型基验证、模型基制造、模型基服务)中至少一项展开了实质性投入[1]。然而,"碎片化的数字化举措"使得多数企业难以将零散的能力整合为完整的数字线程:在领先航空与防御项目的实证统计中,全周期工作量中非增值(NVA)部分约占 50%–57%,单个设计被返工 2.5–3.6 次[1]。
本报告聚焦 Capvidia 公司的 MBDVidia for MBE 产品族,研究其作为"MBD 语义中间件"如何在企业既有 IT 架构(PLM/ERP/MES、各类 CAD/CAM/CMM 工具)之上以轻量化、非侵入方式嵌入,进而打通"设计—工艺—质检"在同一份语义 MBD 模型上的协作通路。研究依据来源于:(i) Capvidia 官网公开信息[2,3];(ii) MBDVidia Enterprise Server/Client 官方架构、部署与许可文档[4,5,6];(iii) MBEServer REST API 与 MBE Client CLI 接口文档[7,8];(iv) Lockheed Martin 公开发布的《2025 MBE Playbook for Suppliers》中对 MBDVidia 在 AS9102 自动化首件检验中的引用[9];(v) Deloitte 发布的 MBE 能力转型白皮书[1];(vi) 国际工程协会(ITI)发布、由前 Raytheon 公司 MBE 负责人 D. Baum 撰写的 MBE/MBM 实施建议白皮书[10];(vii) 国际同行评议的 MBD/MBE 综述与原始研究[11,12,13];(viii) 中国学者关于质量信息框架(QIF)的最新综述[14];(ix) 由 NSE MBIT 委员会发布的 NSE MBE Maturity Index(成熟度评估模型,2026 年 C.1 版)[15]。
研究的关键发现可概述为四点:第一,MBDVidia for MBE 的定位并非 CAD/CMM 的替代品,而是位于 PLM 主干和 CAD/CMM 端点之间的"语义解析—校准—中性输出"中间件;其部署采用客户端/服务器(C/S)架构,支持单机、分布式、控制台和 Windows 服务多种运行模式,通过 REST API 与 PLM/CAM/CMM 旁路集成[4,7];第二,其输出严格遵循国际中性标准——STEP AP242(ISO 10303-242)模型与 QIF(ISO 23952:2020)质量信息框架文件,并辅以人可读的 3D HTML 轻量化派生件,使下游消费工具无需绑定于特定 CAD 厂商[3,11,12,14];第三,行业实证表明,基于 MBD 与 QIF 的自动化首件检验(FAI)可将检验编程时间缩短 ~75%,整体 FAI 准备时间在某些类型件上可降低至 ~90% 区间[9];第四,企业级落地宜采用"小范围试点 → 单项目验证 → 横向推广"的渐进路径,并对照 NSE MBE 成熟度指数(L0 图纸中心 → L6 扩展型 MBE)滚动评估[15]。
报告强调:"非侵入式部署 + 标准中性数据 + 与 PLM 的事件驱动旁路"是 MBE 落地的现实可行解。其本质并非用一套软件替换企业既有体系,而是用一根"语义保真"的数字线程将设计、工艺与质量在同一份可信 MBD 模型上"再缝合"。
────────────────────────────────────────
第一章 工业制造企业的数据协同困境与 MBE 转型诉求
────────────────────────────────────────
1.1 传统"设计—工艺—质检"基于文档协作的痛点
在传统的、以二维图纸为核心的产品定义工作流中,设计部门生成图纸,工艺部门读图重建数字制造模型,质量部门再从图纸出发编写检验程序——每一次跨部门移交都伴随着"重新建模 + 人工转译"。这种基于文档的协作模式带来三类典型痛点:
(a) 信息断裂。原始三维模型与二维图纸往往各自独立维护,二维图纸频繁作为"权威信息"被首选引用[11]。Deloitte 在多家航空与防御项目中的统计显示,单一项目周期内仅"接力交接(handoffs)"次数即超过 2,000 次,其中初始版本之后还会发生 6,000 余次后续修订;约 230 个工日的非增值工作可以直接归因于"孤岛化的流程与指标"[1]。
(b) 重复录入。同一组几何尺寸、公差、材料属性,常常被设计、工艺和质量三个部门各自录入一次到本部门的工具系统中。研究表明,在向 MBD/MBE 过渡的样本企业中,"工程数据在企业范围内的复用率"可由 2% 提升至约 59%[1]——反之亦印证传统模式下重复录入的严重程度。
(c) 版本混乱与图纸二义性。传统工程图依赖人工识读 GD&T 标注、引用基准与公差结构,"同一标注在不同工艺/质量人员处理时给出不同解释"是引发返工的高频根因。已有研究指出,源于"图纸表征到三维特征对应错误"的下游差错可在制造与检验中被进一步放大,仅靠人工二次校核难以根治[13]。
1.2 为什么必须走向 MBE——数字线程作为解决方案
MBE 是一种以"三维模型 + 语义 PMI"作为产品定义唯一权威源,并将产品定义、工艺定义、质量定义、运维定义在统一数据骨架上串联起来的组织模式[11]。其灵魂是"数字线程(Digital Thread)"——一种数据驱动的体系结构,将产品全生命周期中"设计—制造—维护"的权威信息流连接起来,使任何时点的产品与流程状态都可被定位、追溯与重用[9]。
数字线程的价值不在于"采用了 3D 模型",而在于:(i) 工程几何、PMI、属性元数据与下游消费需求被绑定在同一份机器可读对象上,使工艺与质检无需"凭经验再解读图纸";(ii) 制造阶段产生的 As-Built、As-Processed、As-Tested 数据,可通过 QIF/MTConnect 等中性格式回写至原始模型特征,闭环形成可追溯的产品数字孪生[9]。
1.3 企业现实约束:已有 PLM/ERP/MES 系统,不能推倒重来
绝大多数高端制造企业已经在 PLM(产品生命周期管理)、ERP(企业资源计划)和 MES(制造执行系统)上投入了多年的预算与组织习惯。在这类企业内推行 MBE,几乎不可能选择"换掉 PLM 重新搭建"的极端方案。MBE 转型不是"信息化系统升级",而是"业务流程再造",必须充分尊重既有 IT 投资[1]。
正是在这一现实约束下,"MBD 语义中间件"型方案具备落地价值——它以"插件"或"微服务"形态嵌入既有体系:以 PLM 为数据骨干维持不变,CAD 端工具继续承担原生建模任务,CAM/CMM 端的设备程序依旧由现场产线生成;中间件只在三者之间承担"语义解析、PMI 校准、中性导出与回写"的"翻译—校准—桥接"职责。Capvidia 在其公开介绍中将自身定位为帮助企业"实现从设计到生产的无缝转变 ⋯⋯ 自动化工程通信,建立真正的数字线程"的供应商[2],与上述定位高度一致。
────────────────────────────────────────
第二章 理论基础:MBD 与 MBE
────────────────────────────────────────
2.1 什么是 MBD(Model-Based Definition,模型基定义)
MBD 是以三维数字模型为产品定义的唯一权威载体,将原本由二维图纸承载的全部产品信息(包括几何、公差、表面特性、注释、属性、要求等)整合到 3D 模型本体中的一种工程定义方法[11]。ASME Y14.41 标准对"模型"的定义为"由设计模型、注释和属性组合而成的产品描述"[9]。
MBD 数据集(Data Set)通常包含:(i) 三维实体几何模型;(ii) 嵌入式 PMI(Product and Manufacturing Information,产品制造信息)——含尺寸、几何公差(GD&T)、基准、表面粗糙度、注释等;(iii) 配套的元数据(材料、版本、零件号、关联文档);(iv) 视图布局、剖切、爆炸等供下游消费的"呈现层"信息[11,15]。
MBD 与传统二维图纸的根本差别在于:MBD 中的 PMI 不仅是"图形上的标注",而是"语义化"的——计算机能够直接读取并理解每一条标注所指向的 3D 特征、关联的基准、引用的公差类型。这种"机器可读 + 人可读"的双重特性,使其可被 CAM 与 CMM 设备直接消费[2,9]。
2.2 什么是 MBE(Model-Based Enterprise,模型基企业)
按 NIST 的定义,MBE 是"运用建模与仿真技术整合并管理与产品生产与全生命周期支持相关的技术与业务流程的组织"[9]。学术综述将 MBE 的能力维度归结为:生命周期信息、设计/制造/检测、装配、维修/翻修(MRO)、工艺规划、工程更改管理、以及产品定义的当代数字化七个领域[11]。
Deloitte 进一步将完整的 MBE 数字主线划分为四类数字孪生:产品与系统孪生(Product & System Digital Twin)、供应链孪生(Supply Chain Twin)、智能工厂孪生(Smart Factory Twin)、连接服务孪生(Connected Service Twin);其下分别由 MBSE、MBD、模型基供应链/制造、模型基维护这四类业务能力支撑[1]。这意味着 MBE 不仅是"工程部门内的 3D 化",而是覆盖业务、采购、生产、售后的整体性数字化范式。
2.3 MBE 与 PLM/ERP/MES 的关系:PLM 是主干,MBE 是运行模式,MBD 是血液
在概念关系上,三者并非"互替"关系,而是"分层共生":
— PLM(含 PDM、CM)是数据治理的主干,承担"产品对象 / 版本 / 流程 / 权限"的全生命周期管理职责,构成企业的"骨骼"。
— MBE 是企业整体的运行模式,是组织如何让"模型+数字线程"成为日常协作语言的方式,构成"神经与运行机制"。
— MBD 则是流动在 PLM 骨干与各业务节点之间的"血液"——具有语义化、机器可读、可派生且可被各类下游消费的工程定义本身。
值得注意的是,MBE 转型几乎一致地强调:"不要把它做成 IT 实施"。Deloitte 在其多年实施经验总结中提示:"实施应当基于业务流程,而非 IT 项目;MBE 不是工程职能的内部活动,而是要在工程、制造、供应链、客户与服务侧形成对齐"[1]。Baum(前 Raytheon MBE 负责人)则将 MBD/MBE 推行总结为三阶段流水线——规划、设计、执行——并强调"协作 + 执行 = 结果"[10]。
2.4 关于 PMI 与"语义"的进一步说明
PMI 标准化是 MBD/MBE 能否真正"自动化下游消费"的关键。ASME Y14.41/Y14.46/Y14.47 系列、ISO 16792、STEP AP242(ISO 10303-242)、QIF(ISO 23952:2020)等标准共同构成了"机器可读 PMI"的标准基础[9,11,12,14]。其中:
— STEP AP242 提供面向 CAD 几何与 PMI 的中性交换格式;它支持几何尺寸、公差、基准引用、表面状态等的语义化表达[11]。
— QIF 是面向"质量信息全生命周期"的开放数据模型,已于 2020 年正式被国际标准化组织(ISO)接受为 ISO 23952:2020,标志着从行业标准到国际公认标准的跃升[14]。QIF 由数字计量标准联盟(DMSC,成立于 2005 年)维护,自 2013 年发布 V1.0 起经历多版迭代[14]。
— 在"人可读但轻量"的呈现层派生件方面,行业内存在两条并行路径:(a) 3D PDF(ISO 32000-1)——基于 MIL-STD-31000 定义的"3-Dimensional intelligent (3Di)"派生件,配套通用 PDF 阅读器供人员查阅[9];(b) 3D HTML——以纯浏览器即可查看的方式承载 3D 几何、PMI 与视图布局,无需安装专用阅读器。两者文件容器与查看体验不同,是不可直接互换的派生件形态;本报告聚焦的 MBDVidia for MBE 在其轻量化派生件中采用 3D HTML 而非 3D PDF(详见第四章 4.3 节)[3,4]。
────────────────────────────────────────
第三章 向 MBE 转型的必要性
────────────────────────────────────────
3.1 效率:消除"设计→工艺→质检"重复建模与人工转译
效率收益主要体现在三类工作量的削减:(i) 检验/制造程序的"再建模"——下游用图纸重建 3D 模型的劳动被消除;(ii) 工艺与质量人员"再解读"标注的劳动被显著削减;(iii) 报告类(首件检验报告 FAIR、生产件批准过程报告 PPAP)自动生成。
Lockheed Martin 在其面向供应链的 MBE 公开材料中指出:"MBE 实践可使设计与工程工作的速度提高 2 至 3 倍;机加工与检验编程的跨度可降低至原来的约 1/10(即削减约 90%)"[9]。其首件检验(FAI)流程的实证显示,使用基于模型的工具(公开材料中以 MBDVidia 为例)自动生成预填充的 AS9102 表单(含模型特征"气球图"自动标注)后,供应商完成 FAI 的整体耗时可减少约 90%;CMM 检验编程从模型直接派生后,单次检验耗时可减少约 75%[9]。
3.2 质量:消除图纸二义性导致的制造/检测偏差
二维图纸的"二义性"在 PMI 缺失或人工识读阶段被频繁放大。Khan 等学者的实证研究指出,二维标注本质上"上下文相关"——一个简单的"10"可能指代孔径、槽宽、圆角半径或深度,取决于绘图惯例、引线位置、视图关联;类似地,可视化相似的 GD&T 符号在修饰符或基准不同的情况下意义可能截然不同;此类误解的下游传播会"破坏自动化的可靠性"[13]。MBD/MBE 通过将语义 PMI 嵌入模型本体并伴随机器可读的形式向下游传递,从源头切断了这一二义性传导链。
3.3 成本:减少因数据不一致引起的返工
返工是 MBE 价值案例中最常被援引的成本项。Deloitte 给出的航空与防御样本统计中,单一项目的总工作量中非增值(NVA)部分占比 53%,必要的非增值(NVAR)2%,真正增值(VA)仅占 45%——意味着平均每 1 元设计与制造投入中只有约 0.45 元用于增值活动,其中 NVA 工时的关键贡献者包括"流程孤岛与指标不一致(约 230 工日)"、"冗余的工程更改活动(约 70 工日)"和"手工录入与审计 EBOM/MBOM(约 124 工日)"等[1]。
3.4 合规:航空航天、医疗等行业对全流程可追溯性的强制要求
航空航天与防御产业链对"全周期可追溯"具有强制性要求。美国国防部 2022 年发布 MIL-HDBK-539《数字工程与建模实践》并配套 DOD INSTRUCTION 5000.97,确立了数字工程在装备系统开发与维护中的政策框架;产业链中的主承制商(如 Lockheed Martin)已据此向供应商发布转型路线图与时间表,并明确"OEM 与供应商如希望在未来数年保持竞争力,须采纳 MBE 概念"[9]。MIL-HDBK-539 对传统模式与 MBE 模式的差异进行了系统对照:项目信息从"邮件附件 + 手抄硬拷贝"转为"标准化数字工作流",关键产品信息须满足 VAULTIS(可见、可访问、可理解、链接、可信、可互操作、安全)原则[9]。
医疗器械、能源等强监管行业亦存在类似要求——MBD 数据须在产品退役后保持长时间的"可访问、可解释、可重现"。学术综述指出,相比传统二维图纸,MBD 在"长期归档与可解释性"上仍面临挑战,但这一矛盾正是推动行业向 ISO/ASME 标准(STEP AP242、QIF)靠拢的根本动力之一[11]。
────────────────────────────────────────
第四章 MBDVidia for MBE 的产品定位与核心角色
────────────────────────────────────────
4.1 MBDVidia for MBE 简介
MBDVidia 是 Capvidia 公司面向"真正的 MBD 工作流"打造的 CAD 翻译与校验软件套件。Capvidia 在其产品介绍中将 MBDVidia 描述为"易用且强大的 MBD 工作流 CAD 翻译软件",其核心理念是"真正的 MBD:CAD 几何 + 人可读且机器可读的语义 PMI"[3]。在企业级版本 MBDVidia Enterprise 之上,Capvidia 进一步推出面向服务化部署的"MBDVidia Enterprise Server"和配套客户端,使整套能力得以以服务、分布式或控制台等多种形态嵌入企业 IT 体系[4,5,6]。
4.2 定位:CAD/CMM 之外、可嵌入既有 IT 环境的"MBD 语义中间件"
MBDVidia软件生成CAD模型检查报告演示
MBDVidia for MBE 的核心定位可概括为以下三点:
(i) 独立于 CAD 与 CMM。它不替代任何 CAD 系统(Creo、NX、SolidWorks、CATIA 等)作为原生建模工具的地位,也不替代任何 CMM 软件作为现场检测程序生成器的地位[3,4]。
(ii) 嵌入企业既有 IT 环境。其服务器端通过 REST API(HTTP/HTTPS)暴露能力,可作为 PLM、CAM、CMM、检验报告系统的"被调用方"接入企业流水线[4,7]。
(iii) 以"MBD 语义"为核心。所有处理都围绕 MBD 模型(几何 + 语义 PMI + 元数据)展开,输出严格以国际中性标准 STEP AP242、QIF 与轻量化派生件(3D HTML)为主——其中轻量化呈现层采用 3D HTML 形态,浏览器即可打开,与基于 ISO 32000-1 的 3D PDF 是两种不同的派生件容器[3,4]。
4.3 三大核心角色
角色一:解析器(Parser)——完整读取多格式 MBD 模型信息
MBDVidia Enterprise Server 在其任务定义中支持的"模型读取/转换"覆盖了主流原生 CAD 与中性格式,包括 CATIA V4/V5、Creo、Siemens NX、SolidWorks、SolidEdge、Inventor、Parasolid、ACIS、JT、STEP、IGES、3D PDF、3DXML、3MF、QIF、STL/AMF 等共 25 余种格式[4]。其许可机制以"读取每种格式"作为独立特性进行授权(例如 mbe.read_creo、mbe.read_step),便于企业按需启用[4]。
MBDVidia轻松搞定CAD档案兼问题
角色二:校准与转换器(Calibrator & Converter)——规范 PMI 标注并导出中性模型
MBDVidia 的核心价值不在于"格式转换"本身,而在于"PMI 的语义保真"。Capvidia 在产品介绍中将其能力概括为五个层面:
(i) 真正的 MBD CAD 导出——发布 QIF 或 STEP AP242 模型;
(ii) 特性清单(BoC,Bill of Characteristics)生成——从 2D 图纸或 3D CAD 中捕获标注以服务 FAI/PPAP;
(iii) PMI 的"治愈与修复"——使 GD&T 成为机器可读;
(iv) 自动化报告——生成可定制的检验表单(FAI、PPAP)并支持 Excel/HTML/PDF 等多种格式;
(v) 数据闭环——将测量结果以 QIF-Results 回写至 MBD 模型[3,9]。
MBDVidia的PMI自动检查与修
服务端的相应任务类型包括 boc_report_template(基于模板的 BoC 报告)、boc_report_3dhtml(3D HTML 形式的 BoC 报告——MBDVidia 通过该任务输出可在浏览器中查看的 3D 轻量化派生件)、boc_report_netinspect(Net-Inspect 报告)以及 converter_* 系列(输出 QIF/STEP/3DXML/JT 等中性格式)[4]。需要指出的是,3D PDF(ISO 32000-1)虽然在 MBDVidia 的解析器侧作为输入格式被支持读取(见前述 25 余种可读格式清单),但 MBDVidia 在轻量化人可读派生件的输出端采用的是 3D HTML 而非 3D PDF——两者是文件容器与查看方式不同的两种派生件形态[3,4]。
在任意浏览器中查看3D模型及PMI标注!
角色三:桥梁(Bridge)——连接 PLM、CAM 自动化与 CMM 自动化检测
MBDVidia 的"桥梁"角色通过两条路径实现:
(i) 与 PLM 的事件级集成:Capvidia 在其 Enterprise Server 任务列表中提供了与 Windchill 的直连(download_windchill_model 任务),可被 PLM 的"检入/检出"等事件触发,自动拉取原生 Creo 模型并启动后续解析与转换[4]。
(ii) 与 CAM/CMM 的中性数据集成:转换后的 STEP AP242 与 QIF 文件作为机器可读的"特性—公差—基准"载体,向下游 CAM 编程与 CMM 编程提供单一可信的数据源。Lockheed Martin 在其向供应链发布的转型材料中指出,将自动化的 AS9102 首件检验表单生成与 CMM 编程能力链接到同一份模型(其公开材料中以 MBDVidia 为例工具),可使供应商在首件检验上的工时降低约 90%、单次检验执行时间减少约 75%[9];其在"未来工作"中还明确推荐供应商考察 QIF 与 MTConnect 在新购设备与软件中的兼容性[9]。
────────────────────────────────────────
第五章 核心重点:MBDVidia for MBE 的部署架构
────────────────────────────────────────
5.1 部署模式说明
MBDVidia Enterprise Server 支持四种典型部署形态[4]:
(i) 单机应用(Single Application)——在一台服务器上完整运行所有任务;
(ii) 分布式服务器(Distributed Server)——采用星型拓扑,由一台主节点(Master)调度多台从节点(Slave A/B/C 等)分担任务,从节点不再向其他节点级联;
(iii) 控制台应用(Console Application)——以前台进程方式启动,便于交互式调试与日志观测;
(iv) Windows 服务(System Service)——以系统服务方式后台运行,适合生产环境长期运行。
客户端则以以下三种方式与服务器交互[4,5,6]:MBE Client(图形界面应用)、MBE Compare Client(专用于模型对比工作流)、MBE Client CLI(命令行工具,用于脚本化与自动化场景)。所有客户端均使用统一的 REST API(HTTP/HTTPS)与服务器通信。

5.2 部署拓扑结构
典型的分布式部署拓扑由以下要素组成(参见官方架构文档[4]):
— 入口:客户端(MBE Client/CLI 或第三方调用方,如 PLM 适配器、CAM/CMM 上位机)通过 REST API 访问"主服务器"地址;
— 主服务器:承担用户认证、任务队列管理、任务调度与监控;本身可选择"仅做调度,不执行任务",将所有 converter/comparator 任务"锁定(locked_tasks)"后转发至下游节点;
— 从节点群:每个从节点登记自己支持的任务类型与并发槽位(n_slot_*),主节点的调度器据此挑选"在线、不锁定、有空闲槽位、当前负载最低"的节点[4];
— 客户端不需要直接访问从节点,从节点可以在内网内隔离运行,仅与主节点之间维持一条受信任的快速链路;
— 任务工作目录:默认位于 %systemdrive%/mbe_tasks/{client_id}/{task_id},内含 in/、out/、temp/ 三个子目录用于输入、输出与中间产物[4]。
5.3 软硬件前置要求
依据 Capvidia 官方安装指南[5,6]与服务器架构文档[4]:
服务器侧硬件建议:
— 现代高性能 CPU(默认按逻辑核心数设定并发上限);
— 内存 ≥16 GB(推荐 64 GB);
— 独立显卡,至少 2 GB 显存,并支持 OpenGL 4.5(在低版本时可切换到软件渲染模式)[4]。
客户端侧硬件建议:现代高性能 CPU、≥8 GB 内存[6]。
第三方依赖:
— 如需使用"直连 CAD 翻译"(converter_creo / converter_nx / converter_solidworks),需在服务器侧安装相应的 CAD 软件;官方列出的兼容版本范围涵盖 NX 11–2312、Creo 4–11、SolidWorks 2021–2024 等[4];
— 如需生成 Excel/Word 报告,需安装并激活 64 位 Microsoft Office 2016 或更高版本[4,5]。
5.4 支持操作系统
服务端支持的操作系统包括:Windows 11、Windows 10、Windows Server 2022/2019/2016/2012 R2/2012、Windows 8/8.1(64 位版本)[4,5]。客户端支持 Windows 8/10/11(64 位)[6]。
5.5 数据库要求
值得注意的是,MBDVidia Enterprise Server 自身并不依赖关系型数据库,其元数据持久化采用了"文件 + JSON"的轻量化模型。核心配置与运行时数据存放在 %appdata%/Capvidia/MBDVidia Enterprise Server/server 下的几个 JSON 文件中:settings.json(服务器设置)、clients.json(客户端注册信息)、queue.json(任务队列)、launcher.json(锁定任务与远程节点列表)、users.json(用户清单)[4]。
这种设计在企业部署中具有显著的实际优势:(i) 不引入 RDBMS 运维负担;(ii) 配置文件可以通过版本控制系统进行变更管理;(iii) 极简的故障恢复(服务器在意外重启后会自动将 run 态任务转入 wait_continue 态并恢复运行)[4]。
5.6 网络要求
— 协议:客户端/服务器及主从节点间统一使用 REST API(HTTP 或 HTTPS);支持 IPv4 与 IPv6[4];
— 端口:默认 48900(可通过 settings.json/listener_port 修改);
— 防火墙:安装期自动写入 Windows Firewall 入站/出站规则各一条;变更端口时需相应调整规则[4];
— 文件大小约束:单文件上限 2 048 MB、单任务输入上限 4 096 MB(可按 settings.json 调整)[4];
— HTTPS:通过对 settings.json 的 listener_protocol 字段切换;需在服务器与客户端两侧安装受信根证书;官方文档给出了基于 makecert / certutil / netsh 的完整证书签发与端口绑定流程[4]。
5.7 安全与权限管理
(i) 身份认证:所有 REST API 调用要求使用注册用户的登录名/口令(基本 HTTP 认证);用户角色分"管理员"与"普通用户"两类,其中如 settings.get、users.add、queue.list_tasks_all 等敏感接口仅向管理员开放[4,7]。
(ii) 客户端隔离:每个用户可拥有多个 client_id(默认上限为 user_max_clients = 50),不同客户端只能看到自己的"虚拟任务队列";只有管理员可以跨用户/跨客户端可见全局队列[4,7]。
(iii) 凭据管理:MBE Client CLI 支持将口令存入 Windows Credential Manager,并通过 store_credentials / list_credentials / delete_credentials* 一组命令进行管理;避免在脚本中以明文形式出现口令[8]。
(iv) 任务资源约束:服务端通过 task_max_memory_mb(默认 8 192 MB)、task_max_run_local(默认按 CPU 逻辑核心数)、task_timeout_run_minutes 等参数对任务的内存与运行时长进行硬性限制[4],防止单任务消耗失控影响整机服务质量。
(v) 日志与可审计:服务器以分卷日志方式记录所有请求(默认 5 卷 × 20 MB),可按 tag/线程 ID/用户/客户端/IP 等维度追溯[4]。
──────────────────────────────────────────────
第六章 核心重点:MBDVidia for MBE 与企业原有 PLM 作业系统的融合
──────────────────────────────────────────────
6.1 融合的总体原则:非侵入式
MBDVidia for MBE 与 PLM 的融合遵循"非侵入式"原则:不替换 PLM、不修改 CAD/CMM 原有数据格式,作为"插件"或"微服务"旁路工作。这一原则在 Capvidia 的对外定位[2]、Lockheed Martin 在向供应链宣讲的 MBE 工具策略[9]、以及 ITI 在 MBE/MBM 实施建议白皮书[10]中均得到一致呼应:成功的 MBE 转型应在企业既有 IT 投资之上"做加法",而不是"另起炉灶"。
6.2 数据层融合
数据层融合的核心是"权威源不变 + 派生件可控":
— 权威源仍由 PLM 持有:CAD 原生模型(Creo、NX、SolidWorks、CATIA 等)作为产品定义的"原生权威源"在 PLM 中被检入与版本管理;
— 派生件由 MBDVidia 受控生成:每当模型版本发生关键状态变更(如检入、发布、变更通过),由 PLM 触发调用 MBDVidia 的对应任务,生成对应版本的中性派生件(QIF、STEP AP242 以及轻量化的 3D HTML)并回写到 PLM 对应零件对象的派生件位[4];
— 数据级"成熟度"对照:派生件管理本身在 NSE MBE Maturity Index 中被作为独立的成熟度维度评估——L0 不创建派生件、L2 仅基本几何与结构化元数据、L3 含图形/文本 PMI、L4 含语义 PMI 并可声明"功能等价"、L5 含面向特定生产过程的精度与表征、L6 含面向多目标过程的精度与多上下文功能等价声明[15]。
6.3 流程层融合:以"事件驱动 + 状态回写"为骨架
(a) 设计发布阶段
设计部门完成 MBD 建模并将原生模型检入 PLM;PLM 在"检入完成"或"晋级到 Released 状态"事件上调用 MBDVidia 的相应任务,自动生成 STEP AP242 派生件与 3D HTML 轻量化派生件,并对模型质量与 PMI 完整性做检查。该阶段产生的副产物(含校验日志、PMI 一致性报告、模型证书)由 PLM 一并归档到原模型对象之下,构成"派生件—权威源"的双向链路[3,4]。NSE MBE Maturity Index 将这一能力对应到"派生件认证"维度:L4 起出现"嵌入持久化关联的派生件验证证书",L5 起验证可基于 PDM/PLM 晋级状态事件自动触发,L6 起跨数字线程实现持续、事件驱动的验证[15]。
(b) 工艺审查阶段
工艺部门以"轻量化 3D HTML"作为人员评审入口(浏览器即可打开,无需专用阅读器);CAM 编程团队消费 STEP AP242 派生件(含语义 PMI)进行加工编程。当工艺审查中发现可制造性问题时,相关条目以反馈记录的形式回写到 PLM 中相应模型版本之下;如需要变更,则由 PLM 的工程变更流程驱动一次新的设计/派生件迭代。Lockheed Martin 提示其供应商:"基于 MBD 的检验计划与工艺计划"将取代传统的纸面计划,并直接消费同一份模型派生件[9]。
(c) 质量检测阶段
CMM 工程师消费 QIF 派生件(QIF-Plan 与 QIF-Resources 模块)作为检验计划的输入,自动派生检验路径与测量任务;执行后产生的实测数据以 QIF-Results 形式写回,关联到 STEP 持久 ID(STEP Persistent ID)以便与原始 MBD 模型的特征一一对应——即 As-Tested 数据与 As-Designed 模型在同一份特征 ID 上闭合[9,14]。该机制在中国学者的 QIF 综述中亦得到系统总结:QIF 通过统一的特征—特性数据模型支持 PMI 的"要求—执行—结果"闭环[14]。
6.4 API 与集成接口
(a) RESTful API
MBDVidia Enterprise Server 暴露的 REST API 路径前缀为 api/v1.2,资源包括 /settings、/launcher、/users、/user、/clients、/queue、/task、/secrets;其中 /queue 与 /task 提供了完整的"任务创建—文件上传—激活—进度查询—结果下载—任务删除"工作流,支持任何任务类型(converter_*、comparator、boc_report_*、download_windchill_model 等)[7]。这意味着 PLM 的事件监听器或脚本可直接以 HTTP 请求方式驱动 MBDVidia 完成具体业务[7]。
(b) PLM 适配器
官方任务列表中已包含面向 Windchill 的下载任务(download_windchill_model)[4]。对于 Teamcenter、Enovia、Aras 等其他常见 PLM 系统,根据 Capvidia 对外宣称的能力,可基于其 REST API + 各 PLM 自身的事件/脚本机制(如 Teamcenter 的 BMIDE 扩展、Windchill 的 OIR 规则)开发轻量级适配器[2,7]。
(c) 客户端 CLI
MBE Client CLI 提供了 add_task / exec_task / list_tasks_* / server_info / encrypt_file / decrypt_file 等 30 余条命令;CLI 内部封装了 REST 调用与认证,配合 Windows 凭据管理器可在脚本环境中完成"无明文口令"操作,是落地企业自动化流水线的便捷工具[8]。
6.5 数据同步机制
— 触发:PLM 状态机驱动;典型触发点包括"模型检入"、"晋级到 In-Process / Released / Production / Service 状态"等;
— 任务排队:MBDVidia 服务端以"先入先出 + 节点空闲度"的策略调度任务;每客户端有独立的虚拟队列上限(默认 client_queue_max_tasks=300)[4];
— 失败恢复:任务在执行中若超时(默认 task_timeout_run_minutes=30)将被中止并标记为 done,由触发方决定是否重试;服务器异常重启后的 run 态任务自动转入 wait_continue 态并被恢复[4];
— 结果回传:以 task.get_output_file 接口下拉到客户端或 PLM 入口适配层,完成派生件回写。
6.6 版本控制
MBDVidia 的派生件以 task_id / 客户端任务目录结构隔离运行时空间[4],但派生件的"业务版本"治理职责仍由 PLM 承担。建议的版本治理模式是:
(i) 派生件不脱离权威源单独流转;
(ii) 派生件命名与归档保留原模型 part_id + revision 信息;
(iii) NSE MBE Maturity Index 的"派生件可追溯性(Traceability)"facet 提供了 L0–L6 的渐进路径:从 L2 的"基本溯源 ID",到 L4 的"链接至权威基线模型并标注派生操作",到 L6 的"端到端、系统化的数字线程级溯源"[15]——为企业制定版本策略提供了对照标尺。
───────────────────────────────────────────────
第七章 实例解析 MBDVidia 工具族在雷神 CMM 量测流程自动化中的应用
───────────────────────────────────────────────
7.1 案例背景
雷神技术公司(Raytheon Technologies)是 Capvidia 在其公开介绍材料中明确列出的客户之一[2]。雷神所属的航空与防御产业链是 MBE 转型的"先行群"——美国国防部的 MIL-HDBK-539《数字工程与建模实践手册》与 DOD INSTRUCTION 5000.97 等政策文件,已自 2022 年起对装备型号项目逐步提出强制性数字工程要求,对供应链的可追溯性提出了"以模型而非文档为权威源"的方向[9]。在这一行业语境下,雷神既是承制商,也是大量主承制商(如 Lockheed Martin、Northrop Grumman、General Dynamics 等[2])项目下的关键供应商,对"自动化检测—自动化报告—数据闭环"具有明确的工程与合规双重诉求。
值得指出的是,前雷神 MBE 负责人 D. Baum 后续在面向行业的 MBE/MBM 实施建议白皮书中,将自己在雷神等航空航天与医疗器械企业的转型经验总结为"规划—设计—执行"三阶段方法论,并强调"早期且频繁地度量与检查设计质量,是 MBD 收益落地的关键"[10]——这一观点构成了下文所述"CMM 量测自动化"实践的内在动因。本章后续具体流程与量化数据,引自 Capvidia 公开发布的雷神 CMM 量测流程自动化案例介绍材料。雷神在该案例中的研发设计端以 PTC Creo Parametric 作为权威 CAD 系统,CMM 现场以 Zeiss Calypso 为典型量测软件,意味着方案需在异构 CAD/CMM 工具链上实现"语义保真"的数字线程贯通。
7.2 变革前的工作流痛点

在引入 MBD 解决方案以前,雷神的 CMM 量测准备流程具有典型的"人机耦合、劳动密集"特征,主要痛点可归纳为两类:
第一类是对人工的高度依赖,可进一步拆分为五个具体表现:(i) 人工转录 GD&T / PMI——质量工程师须从 2D 工程图逐条转录尺寸、公差与基准至 CMM 准备文档;(ii) 经常出现人为解析误差——同一标注在不同工程师处理时给出不同解释,下游缺陷由此被放大;(iii) 对高技能测量工程师产能形成强占用;(iv) 作业模式表现为"人机耦合"——人工准备先行、机器加工后续,机器必须等待人工输入到位;(v) 整体属"劳动密集型"作业,呈现明显的人力上限瓶颈。在更宽口径的合规层面,传统首件检验(FAI,依据 AS9102 标准)同样表现为"识读图纸→填写表单 1–3→编写测量程序→手工录入测量值与判定"的密集型人工链条[9]。
第二类是企业内部测量数据的"孤岛化",具体表现为两点:其一,多源异构数据格式并存;其二,数据标准不统一,缺乏面向 CMM 工位的权威数据源。这一现象在雷神的具体情境中尤为显著——研发设计部门采用 PTC Creo 系统,而质量检测部门采用 SOLIDWORKS 系统;模型文件在跨部门流转中,若不依靠中性数据标准,几乎不可避免地出现 PMI 信息丢失、版本歧义与重复录入。这一异构现实,恰是第六章所述"非侵入式、不可推倒重来"的 PLM 改造原则在零部件层面的具体写照。
从更广的产业链视角看,雷神同时面临上游主承制商按"Data Set Rating 4/6(基于 MBD 的技术数据包,无图纸或仅含派生 3Di 文档)"发布零件采购包的压力,以及"测量结果按特征写回模型"以维持数字线程可追溯性的合规诉求[9]。这两类外部压力,叠加上述两类内部痛点,构成了引入 MBDVidia 工具族的直接动因。
7.3 MBD 解决方案目标与工具链

(a) 解决方案的设计目标
雷神在 Pilot Project 中确立的 MBD 解决方案目标分为"基于流程"与"全域数据应用"两个维度。在流程维度上,方案以六项收益作为锚点:(i) 消除人为转录差错;(ii) 实现设计经验数字化沉淀;(iii) 强化制程稳定性;(iv) 释放核心工程师产能;(v) 以流程驱动替代人员依赖;(vi) 实现作业周期指数级压缩。在数据维度上,方案要求构建"全要素数据可触达体系",并使"数据流与设计模型精准耦合"——这与第二章所述"以语义化 PMI 为血液、以 PLM 为骨干"的 MBE 主张高度一致。

(b) 完整工具链
雷神在 Pilot Project 中部署的 MBD 工具链由"两端 CAD 插件 + 一个中性数据载体 + 一套 CMM 自动编程与验证组件"构成,整体作业流程呈现为五阶段流水线:
(1) 设计端 / Authority Model:在 PTC Creo Parametric 中制作 MBD 模型作为权威源;借助 Capvidia 提供的 MBDVidia for PTC Creo 插件将模型导出为 QIF 格式。该插件的关键能力之一,是自动识别 2D 图纸上的 PMI 标注并将其匹配到对应的 3D CAD 模型特征——若依靠人工转录,需耗费大量人力与时间,而该插件全程在 5 分钟左右自动完成,既减少了对高级质量检测工程师的占用,又消除了人工转录错误,作业时间被指数级压缩。该阶段总用时不到 1 分钟。
(2) 中间件 / Create QIF Data:以 MBDVidia 加载 QIF 格式的 MBD 模型,自动检查并修复模型中的 PMI 标注,确保其同时具备"人可读"与"机器可读"两种语义层;该步骤全过程系统自动完成,用时约 5 分钟。
(3) CMM 计划优化 / Optimize CMM Plan:基于同一份 QIF 模型,由 MetroSage 公司的 Pundit CMM 软件优化 CMM 检验计划,得到内含 MBD Plans / Resources 的 QIF 文档(参考自 Capvidia 案例材料中"MBD-based 的 CMM 量测工作流程概述"图谱[16])。
(4) 质检端 / Run CMM & Analyze Results:由于雷神质量检测部门以 SOLIDWORKS 为主环境,需先经 Capvidia 的 FormatWorks 插件(专为 SOLIDWORKS 设计的 MBD 数据互通插件)将 Creo 来源的 QIF 文件准确接入 SOLIDWORKS;随后由 Origin International 公司的 CheckMate 插件(一款专为 SOLIDWORKS 设计的、必须在 SOLIDWORKS 环境内运行的质量验证与标准化检查工具,用于自动检测 3D 模型、工程图与装配体对企业或行业标准如 ISO、ANSI 的合规性)导入"人机可读的 QIF 模型",输入测头参数配置、CMM 配置等关键信息后,自动生成 CMM 程式并完成工艺净化验证。CMM 现场以 Zeiss Calypso 等量测软件执行实测。
(5) 回写与可视化 / Visualize Results on Model:执行 CMM 检测后,由 MBDVidia 将测量结果以特征级方式可视化呈现于模型之上,使"As-Tested 数据—As-Designed 特征"建立显式绑定,闭合数字线程的最后一公里[9]。
(c) 工具链的两个工程要点
其一,QIF 在整条流水线中充当"中性数据载体",使 Creo 与 SOLIDWORKS 之间的语义传递不再受任一 CAD 厂商私有格式约束,是第六章"非侵入式"原则在零件级的实现;其二,整条链路在不同环节集成了不同厂商的最佳点工具(Capvidia 提供 MBDVidia 与 MBDVidia for PTC Creo、FormatWorks 两端插件;MetroSage 提供 Pundit CMM(目前为CAPVIDIA收购);Origin International 提供 CheckMate;Zeiss 提供 Calypso CMM),通过 QIF 这一中性数据骨架协同运作——这反映出当代 MBE 工具生态"以标准为枢纽、以最佳点工具为节点"的协作范式[14]。
(d) CheckMate 自动编程的可追溯子步骤
值得提示的是,CheckMate 的自动编程并非"一键生成"的黑箱,而是包含工艺逻辑自洽性验证、工艺关联拓扑排序、测量坐标系智能标定、测头运动轨迹规划、运动干涉动态规避、后处理程序等多个细分子步骤的可追溯流程——这与第二章所述"以特征数据为血液"的 MBD 主张高度一致;其每一子步骤所耗时长亦可被显式记录,便于后续工艺改进与异常归因。
7.4 量化收益

依据 Capvidia 公开发布的雷神案例量化材料,对同一道工序在两种作业模式下进行 ROI 评估:
— 旧有工作流程:基准工时约 16 小时,需要大量人工操作;
— MBD 支撑下的新工作流程:总用时 178 分钟(约 2.97 小时),全流程时间削减约 81%(即新流程仅占旧流程的 19%);
— 单次作业相对旧流程节约 13.03 小时;按雷神该工序年累计作业约 80 次估算,年累计减少人工工时约 1,042 小时。
新流程的 178 分钟时间结构具有较强的可解构性,可据此还原"自动化替换了哪些环节":
MBDVidia(QIF 加载与 PMI 修复) 5 分钟
Creo 文件经 FormatWorks 接入 SOLIDWORKS 5 分钟
CheckMate 参数设置 5 分钟
CheckMate 自动编程:
· 工艺逻辑自洽性验证 15 分钟
· 工艺关联拓扑排序 1 分钟
· 测量坐标系智能标定 1 分钟
· 测头运动轨迹规划 1 分钟
· 运动干涉动态规避 20 分钟
· 人工处理(估算) 120 分钟
· 后处理程序 5 分钟
────────────────────────────────────
合 计 178 分钟(≈ 2.97 小时)
可见,新流程内"纯自动化耗时"(除 120 分钟"人工处理估算"外)约为 58 分钟;雷神情境下仍保留的 120 分钟人工兜底,主要用于复杂工况下的工艺判断与异常处理,而非传统模式下的"逐条转录"——这正是 MBE 落地的现实形态:自动化替换了大量重复性、规则性工作,把工程师重新聚焦到判断与决策环节[10]。
为防止读者将此数据误读为"任一软件供应商的普适承诺",本报告同时给出更宽口径的产业链对照区间:依据 Lockheed Martin 在面向供应链的公开材料中给出的实测区间[9],单次首件检验的供应商总耗时削减约 90%、单次 CMM 检验执行时间削减约 75%、整体设计与工程工作速度提升约 2–3 倍、机加工与检验编程跨度可降低至约 1/10。雷神案例的 81% 削减位于上述区间之内,可作为"具体企业落地区间"的样本;而其落地强度仍取决于供应商内部成熟度——这正是下一节所述 NSE MBE 成熟度指数所要度量的对象[15]。
7.5 进一步的工程意义
(i) 跨 CAD 异构的非侵入式桥接:雷神并未为统一 MBE 推倒原有的 Creo / SOLIDWORKS 部门级工具链,而是以 QIF 作为中性载体、以 MBDVidia for PTC Creo 与 FormatWorks 两端插件作为接入器、以 MBDVidia 作为中转校验枢纽,使 PLM 主干完全保留——这是第六章所述"非侵入式 PLM 融合"原则的零件级实证。
(ii) 数据闭环:As-Tested 数据回写到 As-Designed 特征 ID,使后续的设计迭代与失效分析具备完整的特征级证据链[9,14];CheckMate 的工艺自洽性验证、拓扑排序、轨迹规划等可追溯子步骤[16],使"测量为何这样测"亦得以沉淀。
(iii) 跨供应商一致性:由于使用的是 STEP AP242 与 QIF 等中性标准,主承制商与多个供应商之间不再需要绑定特定 CAD 厂商[9],雷神案例中 PTC Creo 与 SOLIDWORKS 的并存即为这一一致性原则在企业内部的微缩演绎。
(iv) 文化、流程与产能效应:在向 MBE 推进过程中,工艺与质量人员从"再解读图纸"转向"在模型上选择特征"——直接结果是流程驱动替代了人员依赖、设计经验得以数字化沉淀、高级质量检测工程师从重复转录中解放、单次作业周期从 16 小时压缩至约 3 小时;间接结果是对操作员培训方式、班组工时结构、绩效度量的连锁影响[1,10]。这一连锁效应,亦是 D. Baum 三阶段方法论中"早期且频繁地度量与检查设计质量"主张得以在工程层面具体落地的写照[10]。
(v) 制程稳定性强化:将"测量任务从图纸再解读 → 模型直接派生",作业流程的人因变异被显著降低,制程稳定性与作业重复性同步增强——这一收益在面向小批量、多品种、高公差等级的航空与防御工况中具有尤为显著的价值[9]。
────────────────────────────────────────
第八章 工业制造企业向 MBE 过渡实施路径建议:从试点到推广
────────────────────────────────────────
工业企业的 MBE 转型不能"一次到位"。综合 Deloitte 的多客户实施经验[1]、ITI 的方法论[10]、Lockheed Martin 的供应链落地路径[9]与 NSE MBE 成熟度模型[15],建议采用四阶段渐进路径,每阶段均以"业务结果可量化"作为完成标准。
8.1 阶段一:环境准备与集成测试
主要任务:
— 在沙箱环境中部署 MBDVidia Enterprise Server(单机模式 + 控制台启动),完成基础许可激活与 OpenGL/CAD 依赖核验[4,5];
— 选定 1 至 2 个 PLM 事件(如检入、发布)作为初始触发点,搭建 REST API 集成的最小可行链路(Minimum Viable Integration)[7];
— 以已有的、内部信任的若干"良性 MBD 模型"作为种子样本,跑通"模型解析—STEP AP242/QIF 导出—3D HTML 派生—回写 PLM"的端到端链路;
— 在 NSE MBE 成熟度指数中完成第一次"As-Is 评估",明确当前的 Capability / Readiness / Adoption 水平[15];
— 建立 MBE 转型的内部 POC 团队(含工程、工艺、质量与 IT),明确指标体系。
完成判定:单链路成功运行 100 次以上,错误率 < 5%;NSE MBE 评估报告完成并形成"To-Be"目标共识[15]。
8.2 阶段二:小范围试点
主要任务:
— 选取一个具体项目作为试点对象。Baum 建议"选择一个项目而非整个业务,并选用有设计、开发与生产经验、敢于推动变革的 MBD/MBM 冠军人选"[10];
— 在试点项目中实现端到端的"设计—工艺—质量"三方流程:设计部门以 MBD 形式发布权威模型,工艺与质量部门消费派生件并以 QIF-Results 回写测量数据;
— 试点期内并行保留传统的纸面/文档流程作为后备,以降低生产风险;
— 度量基线 KPI 与试点后 KPI:检验编程时间、FAI 准备耗时、跨部门工程更改时长、EBOM/MBOM 一致性等。
完成判定:试点项目交付,KPI 指标实现可对外报告的显著改进;NSE MBE 成熟度指数中至少有 2 个类目(如 C1: Product Design Activities、C2: Product Data/Lifecycle Management Activities)取得相对于阶段一的可观测晋级[15]。
8.3 阶段三:全面推广与流程固化
主要任务:
— 从单机扩容至分布式服务器拓扑:按工作负荷与冗余需求增设从节点(Slave),并将主节点的关键 converter_* 任务"锁定"到主节点上禁用,仅作调度[4];
— 启用 HTTPS:完成根证书与服务器证书的颁发与绑定(参考官方 makecert / certutil / netsh 流程),并要求所有客户端安装根证书[4];
— 启用基于 Windows Credential Manager 的"无明文口令"自动化脚本范式[8];
— 把 MBDVidia 与 PLM 的事件触发从"检入"扩展到"晋级状态机的关键节点"(与 Maturity Index 的 L5"基于 PDM/PLM 晋级或工作流事件自动派生派生件"对齐[15]);
— 形成企业级的 MBD/MBE 培训体系(设计、工艺、质量、供应链);
— 全面纳入工程更改管理:保证更改触发的派生件再生 + PLM 派生件更新形成闭环。
完成判定:MBE 在该 BU 内成为主流工作方式(而非例外);与试点期相比,"返工驱动的非增值工时"占比下降;NSE MBE 成熟度指数总体晋级至 L4("Trusted MBD")以上[15]。
8.4 阶段四:持续优化与扩展
主要任务:
— 跨业务单元横向推广:基于阶段三沉淀的流程模板与培训物料,将 MBE 推向其他业务部门;
— 跨企业边界推广:扩展到关键供应商,按 Lockheed Martin 的实践,对供应商做 MBE 成熟度评估,并将通过性结果纳入采购评分[9];
— 与数字孪生/AI 的进一步整合:例如在派生件生成与 PMI 修复阶段引入大语言模型或视觉—语言模型作为"二阶推理",研究表明该类方法在 2D 标注到 3D 特征的上下文映射任务上的精度(F1)可达约 86%[13];
— 与运维端模型回写打通(As-Maintained 数据),最终对照 Maturity Index 的 L6"扩展型 MBE"持续滚动评估[15]。
────────────────────────────────────────
第九章 预期效益与风险对策
────────────────────────────────────────
9.1 效益
(a) 检验编程时间缩短 70% 以上。
Lockheed Martin 公开数据显示,依托 MBD 与 QIF 的 CMM 编程自动化可使供应商单次检验执行时间削减约 75%,FAI 整体准备时间最高可削减约 90%[9]。该收益区间已在多家航空航天产业链供应商中被实证;具体改进幅度依赖于零件复杂度与企业自身成熟度水平。
(b) 因标注歧义引起的质量问题趋近为 0。
PMI 的语义化与机器可读化使"图纸二义性"在源头被切断[13]。STEP AP242 与 QIF 在中性格式层面再次提供了一道"语义保真"屏障[11,12,14]。学术综述指出,PMI 语义验证(PMI Validation)已成为 NIST MBE 项目的重要工作组方向,其目的是"按 ASME 标准对 PMI 进行一致性和有效性检查"[11]。
(c) PLBOM 与 MBOM 一致性可显著提升。
在传统模式下,工程 BOM(EBOM)与制造 BOM(MBOM)由不同部门各自维护,是返工与差错的高频根源。Deloitte 数据表明,仅"手动录入与审计 EBOM/MBOM"一项即可消耗约 124 工日的非增值工时[1]。MBE 模式下,MBOM 直接由 EBOM 派生并保持链接[9],PLBOM 一致性可达 100% 成为可设定目标。
(d) 工程数据复用率显著提升。
Deloitte 数据:工程数据在企业范围内的复用率可从 2% 提升至约 59%;产品配置错误率可下降约 75%[1]。这是 MBE"以模型为单一权威源"的副作用——一旦权威源稳定可信,下游消费即可无差错地反复利用。
9.2 风险与对策
(a) 历史模型缺乏 PMI
存量数据是绝大多数企业的痛点。学术综述明确指出:"新产品引入(NPI)阶段易于采纳 MBD;但绝大多数组织持有以旧式图纸格式保存的传统设计数据,这些数据仍被用于专有产品的制造与服务。将这些数据转换为 MBD 数据集是高价值制造的巨大挑战"[11]。
对策:
— 设立"按需重建"策略:仅对存在新发图纸或修订需要的零件做 MBD 化转换;
— 借助 MBDVidia 的 PMI"治愈与修复(PMI healing & repair)"能力对存量模型做半自动语义补全[3];
— 对仅有 2D 图纸的零件,引入近年快速进展的"上下文感知 2D→3D 映射"技术(Khan 等 2026 年的研究显示该方法在真实零件上 F1 ≈ 86.29%)作为辅助手段,但需保留人工最终评审[13]。
(b) PLM 接口权限不足
事件级集成需要 PLM 的检入/检出钩子、状态机触发器或自定义 OIR/工作流支持;如 IT 部门未预先开放,集成将停留在"客户端手工触发"层面。
对策:在阶段一即由 MBE 团队与 IT 部门达成"事件—API"接口契约;将"事件接口可用性"作为阶段一完成判定的硬性条件之一[2,4,7]。
(c) 质检人员习惯阻力
任何流程级变革都会遇到一线人员的习惯惯性。
对策:在阶段二保留"手动编程模式作为备选",工时从平行计量逐步过渡到 MBE 主导[1,10]。Deloitte 经验提示:"在 MBE 推行中,应警惕'随机的数字化举措'——零碎的数字化项目缺乏整体协同,反而稀释了变革动量"[1]。
(d) 标准演进风险
国际标准本身仍在演进中:QIF V4.0 正在开发[14]、STEP AP242 持续修订、ASME Y14 标准族持续更新[9]。
对策:参与到标准制定中(ITI 白皮书亦呼吁"参与标准制定可帮助企业更早理解解决方案"[10]);同时将"中性标准 + 中间件"作为缓冲层——当标准升级时,仅需在中间件侧升级,不影响 PLM 与产线[3,4]。
(e) 数据安全与知识产权
派生件流转环节涉及"模型数据离开 PLM 安全域"。Lockheed Martin 在其供应链材料中明确指出:未来"网络安全评级较差的供应商可能无法参与基于模型的零件分包"[9]。
对策:
— 启用 HTTPS、限制端口、关闭未使用任务[4];
— 在派生件级别启用 X.509 数字证书与可信根(学术界已有"嵌入 X.509 证书于 3D 模型以实现产品数据认证、授权与可追溯"的成熟方法论[11]);
— 在结果回写、审计日志、用户角色三个维度实施最小权限原则[4,7,8]。
────────────────────────────────────────
第十章 结论与展望
────────────────────────────────────────
10.1 结论
研究表明,MBE 转型在高端制造业中已不是"是否要做"的选择题,而是"以何种代价、按何种节奏做"的方法论问题[1,9]。其根本难点不在于"3D 化"本身,而在于将既有的、巨额投资过的 PLM/ERP/MES/CAD/CMM 体系编织进"同一份语义保真的数字线程"。
MBDVidia for MBE 作为"MBD 语义中间件"的产品定位[2,3],与上述行业现实诉求高度匹配。其核心价值在于:
(i) 以 STEP AP242、QIF 等国际中性标准作为"语义保真"的数据介质(并以 3D HTML 作为浏览器友好的轻量化呈现层派生件),避免企业被锁定到任何单一 CAD 厂商[3,4];
(ii) 以 REST API + 服务化部署形态被嵌入既有 IT 体系,对 PLM 主干以"事件触发 + 中性派生 + 结果回写"的方式协同[4,7];
(iii) 在自动化检测、首件检验、特性清单等典型质量场景中提供了已被产业链实证的、显著的工时与缺陷削减空间[9];
(iv) 部署形态轻量(C/S 架构、文件—JSON 元数据、Windows Service / 控制台 / 单机 / 分布式四模可选),运维负担显著低于"自研中间件 + RDBMS"方案[4]。
需要强调的是:本研究的目的并非为任何特定产品背书。Capvidia 的 MBDVidia for MBE 是本研究框架内被聚焦解析的"参照样品(reference instance)",其展示的"MBD 语义中间件"模式具有方法论意义,行业内具有可比能力的方案也可遵循同一蓝图实施。
10.2 展望
展望未来,MBE 与 MBDVidia 这类中间件的演进有以下三个趋势性方向:
(i) 与人工智能、机器学习的进一步融合:近一年的学术进展显示,视觉—语言模型(VLM)与大语言模型(LLM)已可在"2D 工程标注到 3D 特征的上下文映射"问题上取得 F1 ≈ 86% 的精度[13];类似技术若被纳入"PMI 修复"或"派生件验证"环节,可显著降低存量数据 MBD 化的人工成本。
(ii) 与有限元分析(FEA)等仿真环境的语义桥接:基于 QIF 与 STEP AP242 的几何—公差—变差信息可被自动桥接到 FEA 工具中,使非侵入式的变差仿真(variation simulation)成为 MBE 的"原生功能"——而非额外的工程项目[12]。
(iii) 与企业数字主线的深度交织:MBE 中间件将不再只是"格式翻译器",而是企业数字主线(Enterprise Digital Thread)上的"智能决策节点"——具备自动优化测量路径、预测超差原因、协同 As-Built/As-Tested/As-Maintained 闭环、并与数字孪生协同的能力[1,9,15]。Capvidia 在其对外宣讲中也表达了类似方向:"让每个零件、版本和决策都可追踪、可审计、可操作"[2]。
最后,企业的 MBE 之旅不应被设想为"一次性 IT 项目",而应被组织为"持续迭代的能力建设过程"。NSE MBE 成熟度指数为这一持续过程提供了七级(L0–L6)共识标尺与多维(Capability/Readiness/Adoption/To-Be Target)评估方法[15],是企业进行自我度量与对外沟通的有效工具。
────────────────────────────────────────
附 录
────────────────────────────────────────
附录 A:术语表
— MBD(Model-Based Definition,模型基定义):以 3D 数字模型作为产品定义的唯一权威载体;按 ASME Y14.41 定义,模型是"由设计模型、注释和属性组合而成的产品描述"[9,11]。
— MBE(Model-Based Enterprise,模型基企业):按 NIST 定义,"应用建模与仿真技术整合并管理与产品生产与全生命周期支持相关的技术与业务流程的组织"[9]。
— PMI(Product and Manufacturing Information,产品制造信息):嵌入 3D 模型中的尺寸、公差、基准、表面、注释等下游可消费的工程语义信息[11]。
— GD&T(Geometric Dimensioning and Tolerancing,几何尺寸与公差):按 ASME Y14.5 / ISO 1101 体系定义的"几何与尺寸公差"标注方法[9,11]。
— DMIS(Dimensional Measuring Interface Standard):测量设备的中性数据接口标准,可与 QIF 协同使用[14]。
— PLM(Product Lifecycle Management,产品生命周期管理):企业产品对象/版本/流程/权限的全周期管理体系;典型实现包括 Teamcenter、Windchill、Enovia、Aras 等[2,9]。
— 数字线程(Digital Thread):贯穿设计、制造、维护的权威产品信息流体系结构,使全周期任一时点的产品状态可被定位、追溯与重用[9]。
— STEP AP242(ISO 10303-242):面向产品几何与 PMI 的中性交换格式,是 MBD 派生件的首选格式之一[9,11]。
— QIF(Quality Information Framework,质量信息框架):由 DMSC 发布、2020 年成为 ISO 23952:2020 的"质量信息"全周期开放数据模型[14]。
— 3D PDF(3Di,3-Dimensional Intelligent):按 MIL-STD-31000 定义、基于 ISO 32000-1 的"可视化人可读"派生件,需通过 PDF 阅读器查看[9]。
— 3D HTML:以 HTML 文件为容器、可直接在浏览器中查看 3D 几何、PMI 与视图布局的轻量化人可读派生件;与 3D PDF 同属"轻量化人可读"派生件类别,但容器与查看方式不同,二者不可互换。本报告聚焦的 MBDVidia for MBE 在其轻量化派生件中采用 3D HTML(通过 boc_report_3dhtml 任务输出)[3,4]。
— FAI(First Article Inspection,首件检验):航空航天领域按 AS9102 标准执行的首件验收[9]。
— BoC(Bill of Characteristics,特性清单):自 MBD 或 2D 图纸抽取的、待检验或验证特性的清单[3]。
附录 B:常见 PLM 系统对接配置参数示例
— Windchill:MBDVidia Enterprise Server 内置 download_windchill_model 任务用于检入事件后的模型拉取[4];自定义 OIR(Object Initialization Rule)规则可进一步在派生件生成后将其作为新内容对象关联到主对象上。
— Teamcenter:可基于 BMIDE 自定义业务对象与 Item Revision 的关系;以 Workflow Designer 在状态变更时触发 REST API 调用[2,7]。
— Aras:通过 Aras Innovator 的 server-side / client-side Method 调用 REST API;以 ItemType 上的"onAfterUpdate"等事件作为触发点[2,7]。
— Enovia:基于 3DEXPERIENCE 的 Process Modeler 工作流;以"模型成熟度状态机"上的迁移事件触发[2,7]。
注:以上四例适配模式遵循同一类型范式——"PLM 工作流事件 → MBDVidia REST API → 派生件 → 回写 PLM 模型对象"。具体字段映射应在企业各 PLM 实例中按其数据模型完成对齐[7]。
附录 C:MBD 模型 PMI 标注最佳实践清单
(1) 全部尺寸采用语义化 PMI;二维派生视图仅作为人可读参考[9,11];
(2) 公差按 ASME Y14.5 / ISO 1101 体系标注,基准明确且与功能等价[11,15];
(3) 文本注释尽量结构化(材料、表面状态、热处理、检验要求等以可解析键值对组织)[14];
(4) 模型在检入前完成"业务规则—几何—元数据—语义 PMI"四级模型质量检查(参见 NSE MBE Maturity Index 的 Verification facet:L1 业务规则检查、L2 + 几何、L3 + 元数据、L4 + 语义 PMI、L5 + 产品特性、L6 + DfX/高级分析)[15];
(5) 派生件版本与权威源 part_id + revision 保持一一对应关系[4,9];
(6) 测量结果按 QIF-Results 写回,并以 STEP 持久 ID 关联回原始特征[9,14]。
────────────────────────────────────────
参考文献
────────────────────────────────────────
[1] Deloitte. Navigating the transition to a model-based enterprise. Deloitte Development LLC, 2023.
[2] Capvidia. Capvidia 官网首页 [EB/OL]. https://www.capvidia.com/. 访问于 2026-05.
[3] Capvidia. MBDVidia 产品介绍 [EB/OL]. https://www.capvidia.com/products/mbdvidia. 访问于 2026-05.
[4] Capvidia. MBDVidia Enterprise Server — Architecture & Deployment(官方架构与部署文档).
[5] Capvidia. MBDVidia Enterprise Server — Installation & Licensing(官方安装与许可指南).
[6] Capvidia. MBDVidia Enterprise Client — Installation & Licensing(官方客户端安装与许可指南).
[7] Capvidia. MBE Server REST API Reference(官方 REST API 参考文档).
[8] Capvidia. MBDVidia Enterprise Client CLI — Architecture & Deployment(官方 CLI 文档).
[9] Lockheed Martin Corporation. Accelerating Transformation: Lockheed Martin's Model-Based Enterprise Playbook for Suppliers (2025 Release).
[10] D. Baum (former MBE lead at Raytheon Corporation), ITI Global. Recommendations for Planning, Designing and Implementing the Model Based Enterprise for MBD/MBM (White Paper).
[11] Goher K, Shehab E, Al-Ashaab A. Model-Based Definition and Enterprise: State-of-the-art and future trends. Proc IMechE Part B: J Engineering Manufacture, 2020 (DOI: 10.1177/0954405420971087).
[12] Roth M, Kopatsch J, Wärmefjord K, Söderberg R, Goetz S. Linking Model-Based Definition and Non-Intrusive Finite Element Analysis for Automated Variation Simulation. Computer-Aided Design, 191 (2026) 104003 (DOI: 10.1016/j.cad.2025.104003).
[13] Khan M T, Chen L, Feng W, Moon S K. Context-Aware Mapping of 2D Drawing Annotations to 3D CAD Features Using LLM-Assisted Reasoning for Manufacturing Automation. arXiv:2602.18296v1, 2026.
[14] 楚峻溢, 张祥春, 任占勇, 曾照洋, 彭文胜, 王四宝. 质量信息框架在制造业的应用与研究. 制造技术与机床, 2025(6): 96–107 (DOI: 10.19287/j.mtmt.1005-2402.2025.06.011).
[15] Model-Based Integrated Team (MBIT), MBE Committee (lead editor C. W. Brown, Kansas City Nuclear Security Complex). NSE MBE Maturity Index, Issue C.1, UUR, NSC-614-7804, 18 February 2026. 在线访问:https://www.sandia.gov/mbit-mbe/category/index/.
────────────────────────────────────────
报告完成日期:2026-05-27
────────────────────────────────────────
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)