CATIA二次开发完整指南：从CAA到Automation

引言

达索系统（Dassault Systèmes）的 CATIA 是航空航天、汽车、船舶、高端装备制造领域使用最广泛的高端 CAD/CAE/CAM 平台之一。空客 A380、波音 787、特斯拉 Model 系列、宝马多个量产车型，都是在 CATIA 中完成核心设计与协同工作。

但 CATIA 二次开发的门槛，比 NX、Creo 或 SolidWorks 都要高出一个层级——这不仅因为它的技术栈复杂，更因为达索对 CAA RADE 开发包的授权管控相对严格，许多团队即便有钱也未必能立刻拿到完整 SDK。

本文系统梳理 CATIA 二次开发的四大主流技术路线，帮你在工程实践中做出正确选择。

CATIA 二次开发的四大技术路线

CATIA 提供的扩展能力大致可分为四层，从能力上限由高到低、从授权门槛由难到易排序：

路线	开发语言	授权要求	能力上限	典型场景
CAA RADE	C++	需购买 RADE 授权与签订 CAA Partner 协议	几乎无限制，可深度扩展 UI、增加 Workbench、自定义建模特征	行业模板、企业级专属 Workbench、商业插件
Automation Object	VBA / VB.NET / VBScript / Python (win32com)	仅需 CATIA 基础许可	受 Automation API 暴露范围限制	批处理、数据迁移、出图自动化
Knowledgeware / EKL	EKL 脚本	需 KW Advisor / Expert 模块授权	参数驱动、规则校验、批量建模	标准件族、参数化骨架、合规检查
CATScript / CATVBA 宏	CATVBA / CATScript	仅需 CATIA 基础许可	与 Automation 等价，但开发体验较弱	录制+小调整、临时性脚本

下面分别展开。

1. CAA RADE：能力的”天花板”

CAA（Component Application Architecture）是 CATIA 自身的底层组件框架，几乎所有 CATIA 模块本身就是用 CAA 写的。RADE（Rapid Application Development Environment）是配套的开发工具集，包含 mkmk 构建系统、CodeRADE（基于 Visual Studio 的 IDE 集成）和大量 SDK 头文件。

CAA 的核心是 CATIA 组件模型，它在 COM 思想之上做了进一步封装：

• 组件由若干 Implementation 组成
• 每个 Implementation 实现一个或多个 Interface（IID）
• 组件间通过 QueryInterface 在 IID 之间转换

下面是一段典型的 CAA 代码片段，演示从一个 Part 文档拿到根 Product，并枚举其子件：

#include "CATIAProduct.h"
#include "CATIDocRoots.h"
#include "CATListPtrCATBaseUnknown.h"

HRESULT EnumerateChildren(CATDocument* pDoc) {
    CATIDocRoots* piDocRoots = NULL;
    HRESULT rc = pDoc->QueryInterface(IID_CATIDocRoots, (void**)&piDocRoots);
    if (FAILED(rc) || !piDocRoots) return E_FAIL;

    CATListPtrCATBaseUnknown* pRootList = piDocRoots->GiveDocRoots();
    if (!pRootList || pRootList->Size() == 0) {
        piDocRoots->Release();
        return E_FAIL;
    }

    CATBaseUnknown* pRoot = (*pRootList)[1];  // CAA 列表索引从 1 开始
    CATIAProduct* piRootProduct = NULL;
    rc = pRoot->QueryInterface(IID_CATIAProduct, (void**)&piRootProduct);
    if (SUCCEEDED(rc) && piRootProduct) {
        CATIAProducts* piChildren = NULL;
        piRootProduct->get_Products(piChildren);
        long count = 0;
        piChildren->get_Count(count);
        // ... 遍历 piChildren ...
        piChildren->Release();
        piRootProduct->Release();
    }

    delete pRootList;
    piDocRoots->Release();
    return rc;
}

CAA 的能力上限非常高：你可以新增一个完整的 Workbench，自定义建模特征（Feature），扩展工程图的标注规则，甚至替换 CATIA 自身的某些 UI 行为。代价是：

• 授权门槛：CAA RADE 不在公开市场出售，必须申请加入达索的 CAA Partner 计划，签署 NDA 后才能拿到 SDK
• 学习曲线：CAA 的接口数量以万计，需要熟读 CAA Encyclopedia 与 Live Documentation
• 构建复杂：mkmk 不是 CMake，自带一套依赖管理与平台抽象，迁移到现代 CI 上需要适配
• 版本耦合：CAA 接口在大版本之间会有 breaking change，每次升级 CATIA 都要重新编译

何时选择 CAA：你需要做行业模板、商业级插件、深度定制 UI，或客户已经为 CAA Partner 关系付费。否则不建议作为第一选择。

2. Automation Object：最实用的扩展方式

CATIA 在自身进程内暴露了一套 COM 自动化对象模型，从 Application 起步可以访问几乎所有”用户能在界面上做的事”。这是大多数二次开发项目的主战场，因为它只需要 CATIA 基础许可。

最小可运行示例（Python via pywin32）：

import win32com.client

# 连接到正在运行的 CATIA
catia = win32com.client.Dispatch("CATIA.Application")
catia.Visible = True

# 新建一个 Part
part_doc = catia.Documents.Add("Part")
part = part_doc.Part

# 在原点位置新建草图
sketches = part.Bodies.Item(1).Sketches
ref_plane = part.OriginElements.PlaneXY
sketch = sketches.Add(ref_plane)

# 进入草图编辑模式
factory_2d = sketch.OpenEdition()
factory_2d.CreateLine(0, 0, 100, 0)
factory_2d.CreateLine(100, 0, 100, 50)
factory_2d.CreateLine(100, 50, 0, 50)
factory_2d.CreateLine(0, 50, 0, 0)
sketch.CloseEdition()

# 凸台拉伸
shape_factory = part.ShapeFactory
pad = shape_factory.AddNewPad(sketch, 20)
part.Update()

# 保存
part_doc.SaveAs(r"D:\catia\demo.CATPart")

VBA 宏的写法几乎一致，差别仅在于 VBA 在 CATIA 进程内运行（通过 Tools → Macro），而 Python 通过 win32com 跨进程通信。

适用场景：

• 批量处理：从 Excel 表格读取参数，循环生成数百个变体零件
• 数据迁移：批量提取 BOM、属性、装配树到 ERP/PDM
• 工程图自动化：批量生成视图、批量打印 PDF
• 与 Creo 自动化方案做横向对比时的对位实现

局限：

• 不能扩展 UI（无法新增自己的 Toolbar 或 Workbench）
• 不能定义新的 Feature 类型
• 部分高级模块（如曲面、电气、管路）的 API 覆盖率不如建模/装配模块完整
• Automation 调用的性能开销不低，处理大型装配（万级零件）要小心循环写法

3. Knowledgeware/EKL：参数化与规则的最强武器

Knowledgeware（KW）是 CATIA 内置的知识工程层，提供参数、公式、规则、检查、Knowledge Pattern 等能力。EKL（Enterprise Knowledge Language）是 Knowledgeware 使用的脚本语言，语法类似 BASIC 与 SQL 的混合体。

KW 的最大优势是与建模本身原生集成——你写的 Rule 直接挂在 Part 上，重新打开零件时规则自动重新计算，不需要外部宿主程序。

一个最简单的 EKL Rule，用于自动设置法兰盘的螺栓数量：

let nBolts(Integer)
nBolts = round(`Parameters\OuterDiameter` / 50)
`Parameters\BoltCount` = nBolts

Knowledgeware 是专题文章的主题，详细内容请见 CATIA Knowledgeware 与 EKL 参数化设计。

4. CATScript / CATVBA 宏：录制即开发

CATIA 内置的宏录制器（Tools → Macro → Start Recording）会把你的鼠标操作翻译为 CATScript 或 CATVBA 代码。新人入门时最便利，但生产环境不建议作为主开发方式：

• 录制结果常常包含冗余调用（界面上的”取消”、“切换视图”也会被录入）
• CATScript 是一种 BASIC 方言，不支持类、继承等结构，工程化能力弱
• 调试体验差，没有断点和单步执行

使用建议：用录制器作为”探索 API 调用关系的工具”，把录制结果翻译为正经的 VBA 模块或 Python 脚本，再纳入版本控制。

开发环境搭建

通用基础

无论走哪条路线，以下是必备的：

• CATIA V5 至少 R2018 / V5-6R2018 起步（更早的版本 API 覆盖度差）
• 或 3DEXPERIENCE Platform R2020x 起步（注意 3DEXPERIENCE 与 V5 的 API 已有显著分化，下文专门讨论）
• Visual Studio 2017+（CAA 开发需要）
• 建议使用单独的开发机或虚拟机，避免 RADE 安装影响生产 CATIA

Automation 开发栈

最低成本的搭配：

CATIA V5 R2021
+ Python 3.10
+ pywin32
+ Visual Studio Code（编辑器）

如果团队习惯 .NET：

CATIA V5 R2021
+ Visual Studio 2022 + VB.NET 项目
+ 添加 COM 引用：CATIA V5 InfInterfaces (CATIA V5)

CAA RADE 开发栈

申请到 RADE 授权后，安装通常包含：

• CAA C++ SDK（按 CATIA 大版本对应）
• mkmk 构建工具
• CodeRADE for Visual Studio 插件

CAA 工程的目录结构是固定的（FrameworkName / IdentityCard / Module / src / LocalInterfaces），不能像普通 C++ 项目那样自由组织。这是一个高频踩坑点。

代码版本控制

CATIA 自身的二进制文件（CATPart、CATProduct、CATDrawing）不要直接进 Git，会迅速膨胀仓库。推荐：

• 二进制走 LFS 或外部 PDM
• 仓库里只存源代码（VBA / Python / EKL / CAA C++）和文本格式的元数据
• 用 ENOVIA / 3DEXPERIENCE 管理 CAD 数据，Git 管理脚本

典型场景与路线选择

场景	推荐路线	理由
批量参数化建模（族表式）	Knowledgeware + Automation	KW 做规则，Automation 做批量驱动
自动出图	Automation	API 覆盖完整，Drawing 模块的 Automation 体验好
自定义 Workbench / Toolbar	CAA RADE	Automation 做不到
标准件库	Knowledge Pattern + Power Copy	与建模深度集成、可在 ENOVIA 共享
数据迁移到 ERP	Automation	跨进程调用，与 ERP 集成方便
合规性检查（如壁厚、最小圆角）	Knowledgeware Check	Check 在保存时自动触发
模型对比/差异分析	CAA RADE 或 Automation	简单对比 Automation 即可，深度对比需 CAA
与 PLM 的双向同步	CAA RADE + ENOVIA SOA	需要 ENOVIA 的 SOA 接口

与 ENOVIA / 3DEXPERIENCE 的集成

ENOVIA 是达索的 PLM 平台。在 V5 时代，CATIA 与 ENOVIA 通过 VPM Navigator 或 CATIA-ENOVIA Workplace 集成；3DEXPERIENCE 时代统一为 3DEXPERIENCE Platform，CATIA 直接作为其中的 App 运行。

集成层面的开发能力：

• ENOVIA SOA：基于面向服务架构的 Web Service 接口，可用 Java / .NET 调用，做与外部系统的双向同步
• 3DEXPERIENCE Web Services：REST 风格的 API，认证走 3DPassport
• MQL/TCL：ENOVIA 内核的脚本语言，用于服务端定制
• Knowledge Pattern with PLM References：Knowledgeware 直接读 ENOVIA 中的引用对象

类比来看，ENOVIA + CATIA 的关系，与 Teamcenter + NX 非常相似——都是同厂 PLM 与同厂 CAD 的”原生协同”，但接口与术语完全不通用。

常见陷阱与避坑

1. CATIA “假死” / Automation 卡顿

CATIA 的 Automation 调用是单线程同步的。当循环里有大量调用时，CATIA UI 会冻结。优化思路：

• 在循环外缓存 Application 引用，不要每次重新 Dispatch
• 大量修改 Part 时把所有 Update() 推迟到循环结束后统一调用一次；中间不要逐个特征触发更新（CATIA 的 Update 代价是按特征数 × 关联特征数累加的）
• 同样可以临时关闭可视刷新：catia.RefreshDisplay = False，循环结束后再恢复 True，对仅做几何/参数批改的脚本能减少 30%~50% 耗时
• 不要频繁切换 Workbench

2. CATIA 与 Office 的位宽错配

CATIA V5 自 R19 起提供 64 位版本，R2014（V5-6R2014）之后官方仅维护 64 位发行版；如果客户现场仍在用更早的 32 位 V5，必须使用 32 位 Python 与 32 位 Office 来桥接 Automation。实操要点：先在 CATIA 启动画面或 About 中确认 V5 的位宽，再选择对应位宽的 Python（python -c "import struct; print(struct.calcsize('P')*8)"）和 Excel；位宽错配会在 Dispatch("CATIA.Application") 阶段直接报 class not registered。

3. 文件路径中的中文与空格

SaveAs / Open 等接口对中文路径支持不稳定。建议工程内统一走纯 ASCII 路径，或使用短路径 API 转换。

4. License 检查时机

某些 API（如 KnowledgewareToolbox）需要对应的 KW 模块授权。如果团队中只有部分人有 KW 许可，脚本要先用 try ... catch 检测，给出友好的错误提示而非直接崩溃。

5. 3DEXPERIENCE 与 V5 的 API 差异

迁移到 3DEXPERIENCE 时不要假设 V5 的代码可以”原样跑”。差异点：

• 文档存储：V5 是文件，3DX 是数据库引用（PLM Reference）
• 发布对象：3DX 引入了 Configuration / Effectivity，规则更复杂
• Automation 部分接口被弃用，部分接口签名变化

迁移前用一份 PoC 项目摸清楚边界，再决定是改 Automation 还是迁到 CAA。

6. CAA Partner 协议的法律边界

CAA SDK 是受 NDA 保护的资产，开发出的模块默认归属甲方所有或受协议约束。在外包项目中要明确知识产权归属、是否可对外发布、是否需要走达索的认证（CAA V5 Approved 标识）。

总结

CATIA 二次开发的世界比 NX/Creo/SolidWorks 都更”垂直”——上限极高（CAA RADE 几乎可以做任何事），但门槛也最高。对绝大多数企业用户来说，Automation Object + Knowledgeware 就足以覆盖 80% 的诉求。CAA RADE 是真正的高地，留给那些有商业插件计划或行业模板战略的团队。

进一步阅读：

• CATIA Knowledgeware 与 EKL 参数化设计 — 本系列专题篇
• NX 二次开发完整指南 — 同体系横向对比
• Creo 参数化设计自动化 — 中端 CAD 的参数化思路
• SolidWorks 二次开发指南 — 与 CATIA 同属达索

如果你的团队正在评估 CATIA 二次开发的技术路线，欢迎联系青岛辰时——我们在航空航天与高端装备行业积累了多年的 CATIA 工程实践。