5.1 多用户协同设计

5.1 多用户协同设计

本节摘要：SOURCE 5.1：PLM/PDM 管理版本与权限；云 CAD 支持实时协同评审与 check-out/check-in 流程。

一个外协项目的协同难题

某设备厂接了一个 OEM 项目：本厂设计、外协厂加工、客户驻场评审。三个角色三种诉求：设计师要"能改"，外协要"能看、能量"，客户要"能审、能追溯"。如果没有协同机制，文件会在邮箱里来回飞：谁发的是最新版？客户审的是哪一版？外协加工用的是不是改废的一版？

协同设计的本质，就是把"文件飞来飞去"变成"单一数据源 + 受控访问"。所有人都围绕同一个权威版本工作，谁改了什么、谁批准了什么，全程留痕。

三种协同模式

文件锁（check-out/check-in）：修改前"借出"文件获得独占锁，改完"归还"入库。优点是实现简单、语义清晰；缺点是串行化——A 借出期间 B 只能干等。

分支合并：像 Git 一样各改各的分支，最后合并。适合并行开展互不冲突的设计任务；但三维模型的合并远比文本冲突复杂，需要"语义级"合并而非逐行合并。

实时共编：基于 OT（操作变换）或 CRDT（无冲突复制数据类型）实现多人同时编辑同一模型。适合概念阶段的头脑风暴式评审，实时看到彼此的修改。

PDM：协同的中枢

PDM（产品数据管理）是协同的中枢，承担四类核心职责：

数字主线：变更的自动联动

数字主线（Digital Thread） 要求 CAD 变更触发 BOM、工艺、运维文档联动——螺栓改尺寸的例子即源于此。数字主线的实现依赖"关联"而非"通知"：

• 装配引用零件的版本；
• 工程图引用模型的参数；
• BOM 引用装配结构；
• 工艺引用特征的制造语义。

这些引用构成一条链：改源头 → 下游全部重算。数字主线把"变更"从"人工通知"变成"数据自动传播"，是从根上消除"用旧版数据干活"的手段。

# 变更影响分析：沿引用链找出所有受影响对象
def impact_analysis(model, change):
    visited, queue = set(), [model]
    affected = []
    while queue:
        cur = queue.pop()
        if id(cur) in visited:
            continue
        visited.add(id(cur))
        affected.append(cur.name)
        for ref in cur.references:      # 谁引用了它
            queue.append(ref)
    return affected                      # 如 ['bolt_m14', 'flange.asm', 'drawing_A3', 'bom_sheet']
​

外协与 IP 保护

⚠️ 常见坑：外协发原生文件泄露 IP——应发 STEP+图纸包并控权限。

外协协作遵循"最小必要信息"原则：

1. 不发原生文件：原生格式含全部特征与设计历史，属于企业核心资产；
2. 发 STEP + PDF 图纸：STEP 保几何供加工测量，PDF 图纸供工艺阅读；
3. 按角色控权：外协账户只读、只下载指定文件，不授予管理员权限；
4. 留痕审计：所有下载、浏览、修改操作记录在案。

变更管理：全生命周期的"稳压器"

变更管理（ECR/ECN）是协同的闭环：任何设计变更必须经过"申请→影响评估→审批→执行→归档"。影响评估是核心——改一个尺寸，到底会影响多少文件？ 影响分析依赖的数字，正是引用链的完整性。引用链不完整（比如有工程师把尺寸硬编码在工艺文档里），影响评估就会漏判，变更就会在制造现场"爆炸"。

协同的技术底座

现代协同系统普遍采用事件驱动架构：模型变更产生事件，事件驱动下游更新与通知。配合轻量化查看（Web 浏览器只读浏览模型）、批注系统（在模型上贴意见）、以及自动快照（定时保存版本），形成完整的协同闭环。

💡 关键直觉：协同核心是可追溯的版本与权限。

一次在线评审的完整流程

协同设计最典型的高频活动是在线评审。以"客户评审支架装配方案"为例，完整流程是：

1. 发布轻量化模型：把大装配转成 Web 可查看的轻量化格式，生成只读链接；
2. 邀请与会者：设计师、工艺、质量、客户按角色分权限加入；
3. 标注与讨论：各方在模型上添加批注（"此处间隙过小""Φ12 孔改 Φ14"），实时可见；
4. 结论固化：评审主持人把批注汇总为修改任务，关联到 CAD 特征；
5. 闭环追踪：修改完成后，任务状态更新，评审记录归档备查。

关键点是评审结论必须可追踪：口头"这个孔改大点"没有任何效力，只有落到"批注 → 任务 → 修改 → 验证"的闭环里，评审才有价值。

def review_workflow(comments, model):
    tasks = []
    for c in comments:
        if c.resolution == "modify":
            tasks.append({
                "feature": model.locate(c.feature_ref),  # 批注绑定特征
                "params": c.suggested_params,            # 建议参数
                "owner": c.owner,                        # 责任人
                "status": "pending",
            })
    return tasks    # 任务与特征绑定，修改后自动核销
​

版本历史：设计的"时间胶囊"

版本管理是协同的基石。一次规范的版本记录至少包含：

可追溯的版本历史，让"回滚到上一版"不再是灾难——工程师敢于试错，因为每一步都有退路。

冲突处理：从"几何互斥"到"语义协商"

实时协同的难点是冲突。两个设计师同时编辑同一零件的不同特征：

先进系统采用"特征粒度锁定"：不同特征并行编辑，同一特征只有一个作者可改。合并时做语义检查，而不是简单的文本合并——这比 Git 的逐行合并复杂得多，也是云 CAD 的技术护城河。

变更通知与订阅

变更只有"被知道"才有意义。现代 PDM 提供订阅通知：设计师关注某零件，一旦它升版或被修改，立刻收到通知并查看变更对比。数字主线把通知从"人工转发"升级为"订阅自动推送"——信息传播零延迟、零遗漏。

轻量化：协同的"减重"利器

轻量化（Lightweight）技术把大模型压缩到可实时浏览的规模：

轻量化不是"降质"，而是"按需取质"：评审时看形状与批注足够，加工时才加载完整精度模型。外协供应商拿到轻量化链接即可参与评审，而无需安装重型 CAD——这大幅降低了协同门槛。

要点速记

• PDM 是协同的中枢
• 轻量化降低外协门槛
• 变更管理连接全生命周期
• 三种模式：文件锁/分支合并/实时共编
• 数字主线 = 引用链 + 自动传播