根据前一篇博客，协同设计包含了一系列可以实现清晰可见、差异比较、选择合并等功能的、非常棒的工具。终端用户看到的功能和交互只是协同设计的冰山一角，实际上，协同设计系统的后端决定了它的有效性。一个组织良好的核心结构，为无缝协同奠定了基础。
使用严格的管理系统在软件开发公司是一项强制性的事情。由于有太多的人群从事代码设计，而且每天都会产生很多的版本，如果没有一个管理系统来控制它们，那么每个开发过程将都会是一个烂摊子。在软件设计行业，版本控制作为公司文件管理的作用已经得到了充分验证，所以我们把它用在电子协同设计系统是非常有意义的。
版本控制：只是一个简单概要
Anyon任何熟悉版本控制系统的人都知道主体、分支、合并和标签。
主体是指设计或项目的开发主线，主体的最新版本为修订版。根据不同设计师对于不同领域的项目的修改，由此产生多个分支。所以，会同时存在几条平行设计是非常可能的,实际上，在协同设计过程中是不可避免的。在开发过程中，它们最终会整合成为最终设计或者里程碑。
图1：在一个版本控制系统，开发过程被管理成为主体，平行展开的设计被称之为分支。分支可以合并到主体，也可以舍弃，每一个特定的里程碑都可以被标记。
使用协同设计比较工具，分支可以被合并或舍弃，这取决于它与最终设计的相关性或实用性。如果某些分支不具有添加到最新修订版本的任何有用信息，那么就会被舍弃。而如果这一分支进程可以影响最终设计，那么部分设计更改需要合并到主体，生成最新的修订版本。
在项目的开发过程中定期地标记修订，可以给项目进行生成快照。标签是用来标识产品开发过程中的一个里程碑。在协同设计的情况下，当把系统设计的分支合并至主体后，它可以作为一个好的基准点。
那么，协同设计一定要使用版本控制吗？
当然，理解了版本控制并不意味着设计工程师可以瞬间无误地进行协同设计。图1帮助我们直观地展现了并行开发。即使界面再复杂的协同设计工具，好像使用了各种复杂、神秘的算法，但是它们的核心还是一个美化后的版本控制系统。所不同的是，之前探讨的结构类型，是通过图形用户界面实现协同设计的。
设计工程师在一个项目中单独地修改自己版本（即：自己的分支），最后这些修改或者被合并，或者被舍弃。协同设计工具帮助设计工程师避免相互冲突，能够高效地处理各种冲突。
构建更好的系统
虽然版本控制是协同设计的良好基础，但是这里还存在更好的实现结构。我们扩展一下设计快照的想法，如果我们能够取得设计快照，并将它放入一个更大的数据管理系统，该系统具有生命周期状态变更和批准的功能，会发生什么呢？这是最终目标，版本控制保留了准确的版本修订历史记录，来帮助保持数据的完整性，但是它不能够维持产品的整体生命周期的数据完整性。如图2，一个产品会跨越多个领域，从供应链、电子设计、机械设计到制造。版本控制在这些独立领域，保留了项目的修订历史，真正的数据管理系统，可以延伸至所需领域，将产品推向市场。
图2：设计发布包括设计方面的所有信息，以及其他相关领域，在特定时间点，将产品推向市场。
电子设计师会担心很多不同的方面及潜在风险，生命周期仿佛是从恐怖片里走出的怪物。产品生命周期管理（PLM）将会管理产品的所有数据，从它的出生到退市。而且它不仅仅管理产品的设计发布。要了解一个设计发布的最佳方法就是从基础开始：
设计发布
- PCB文档
০ PCB封装
∎ 图形
• 焊盘层叠
• 边界
∎ 装配图
∎ 3D机械模型
০ 复用模块
০ 模板
০ 规则和约束
- 原理图文件
০ 原理图符号
∎ 备选视图
∎ 供应链信息
∎ 数据手册
০ 复用模块
০ 模板
০ 引脚交换数据
- 库文件
০ PCB封装
০ 原理图符号
০ 参数数据
∎ 生命周期状态
০ 供应链信息
- 机械装配文件
০ 3D机械模型
০ 3D输出打印
০ 2D CAD制图
- 输出文件
০ 制造输出
০ 装配图
০ 材料清单
∎ 供应链信息
০ 3D输出打印
这是一个自上而下的结构，但是存在着大量不同条目之间的关联和依存。正确的数据管理，可以确保对于所有父子条目的独立管理，以及相应的修订历史记录数据。同样，生命周期管理从始至终、细枝末节地跟踪所有的条目。这可能看起来比较复杂，归根结底，每个设计者只需要关系自己做得修改，系统可以确保每个变更和修改是可见的，并且在需要审批的时刻由管理员批准。项目跟踪不是猜谜游戏，只有当其中所有细节都具备了，产品的生命周期状态才能够向前推动。
能够实现多个领域数据合并的强大平台，远比版本控制系统更加促进团队精神和协同设计。所以，我们认为设计发布过程是最终推动合作的最佳途径，特别对于跨领域而言，另一个有趣话题便是，终端用户如何处理这些领域中的数据？在下一期的系列博客，我们将共同探讨。