|
为什么需要协调？
为什么一个产品开发项目会失败？从技术的角度可以这样解释:在产品设计或其下游活动中，包括工艺、装配、制造等，最终有一个或一些条件没有得到满足。自然地，我们会产生这样的想法:把这些约束条件找出来并监控起来，就能获得成功。事实上也是这样，经验丰富的设计师能够成功的原因就是他们头脑中存在着很多条条框框，使他们能够选择合理的设计结构和参数。协调系统是支持这样一种理念的计算机辅助工具，它能够定量地监控和分析设计中需要满足的约束条件，并提供有效的冲突解决方案。
并行工程的中心思想是应用小循环来代替大规模的返工，而这种代替又会导致大规模的工程更改和交互信息增加，这是串行设计中不存在的问题。以飞行器设计布局为例（布局问题可以简化地看成在一个非常有限的空间内摆放各种部件，不仅要摆得下，还要求合重心在固定的点上），纯粹的串行活动过程是这样的:进行各个部件的开发，包括总体设计、装配，但此时可能出现无论怎样布局也不能保证重心位置，而只能通过增加配重来解决的情形。这时，每一步活动中的设计参数都是确定好的，但也正是由于这样而使当发生冲突时很难更改。那么，一个合理的并行开发过程是什么样的呢？在设计初期，总体组就建立好经过计算的布局模型，然后分配到各个分系统设计小组，在设计过程中，总体组就一直监控各个子系统的开发过程，不断计算设定值与实际值的偏差，直到各个子系统开发完成，这样，即使必须增加配重，也可以在设计的早期就知道，以便决定是增加配重还是进一步调整布局方案。
上述只是一个约束条件——质心约束对整个设计的影响。事实上，这样的约束条件还有很多，例如总体组调整质心要影响到转动惯量，而转动惯量又是控制系统设计的重要参数，因而可能形成一个互相影响的迭代过程。由于各个部门之间参数的互相影响有可能引发部门之间的矛盾，从而发生互相扯皮的现象，这将大大地增加开发风险，降低效率。
以上设计过程的改变充分说明，由串行设计转为并行设计，虽然节约了设计时间，避免了后期的冲突，但却使本来简单的工作复杂化了，预定好的设计信息往往会发生变化，这是由于设计过程的并行化而使设计中不确定性信息大大增加了。在并行工程中，PDM等支持工作流的软件实现了项目人员之间的通信，但仍然存在一些问题，成为制约设计的瓶颈，如相互之间的影响很量化;从信息的发送方来看，要求每个设计人员发布自己的技术设计细节问题，因此而破坏了各个环节技术上的独立性；从信息的接收方来看，由于是公共信息，每个设计人员在理解这些公共信息的时候会发生困难;大量的冗余信息不仅给设计实现造成了不必要的困难，而且频繁地接收与自己无关的信息会给设计人员带来不必要的负担，降低工作效率。
在企业建立适合的协调系统过程中，应以产品设计的实际情况为依据，建立完善的设计责任制，每个设计人员在各自的设计权限和责任的基础上，按部就班地完成整个设计任务。协调系统的最终目标是产品的“一次成功”。
怎样协调？
针对以上并行设计中出现的问题，我们可以看出以下两方面工作是必要的:对于并行设计中重要的约束条件必须要监控；发现冲突后要利用合理的手段加以解决。其中约束网络负责组建一种新型的协同设计模式，监控设计过程，预测设计冲突，其核心技术为一致性算法、约束满足问题求解。冲突仲裁主要利用实例法、基于规则的方法、基于优化的方法来解决设计冲突。
作为支持并行设计的工具，约束网络的存在为在并行设计中定量表示设计之间的关系提供了理论基础。约束网络建立起了一种支持不确定性的并行设计工作模型，设计参数不再是固定的设计值，而是先由设计人员根据经验，给出相应的区间范围，这样就增加了整个设计的柔性。约束网络的目的是辅助全体设计人员确定出一组满足所有约束条件的解。我们在理论上可以证明，通过一致性算法的解可以满足所有的约束条件。当下游设计工作开始时，作为依据的上游设计工作可能还会发生改变，而同时进行的设计工作也会由于工程更改而互相影响，这时，约束网络就可以作为计算并描述这种更改对其余参数影响的一个工具，不仅可以求出影响到哪个设计人员，还可以计算出这种影响有多大。图1是基于约束网络的协同设计监控系统图。 （图片）
图1 基于约束网络协同设计监控系统 以上所描述的只是约束网络在某一时刻所处的状态，而实际上产品开发是一个过程，约束网络的建立、修改和完善是伴随着整个产品的生命周期过程的，所以，图1描述的约束网络是一种面向全生命周期的约束监控系统，使约束网络在概念设计阶段就开始构造建立，伴随着设计的深入，约束网络被不断地修改和完善，直到得到满足要求的设计参数、完成整个设计任务为止。
由于协同设计中各部门都争相考虑自己所属的约束条件首先被满足或取得比较好的变量取值，而且由于约束网络是反映各部门所涉及的约束条件和变量，为了有效地控制整个约束网络，权限配置与设计历史的管理是必需的。
由于我们现在采用的冲突解决技术方法比较多，只在这里做简要的介绍。实例是对实践经验的归纳与体现，具有普遍适用性。在复杂系统模型难以确定的前提下，运用实例法解决冲突，可以不必拘泥于系统的模型与种类。实例法具有可完善、扩展的特性，通过不断解决新的冲突，并将新的实例存入实例库来完善库中实例的种类和数量，逐步扩展实例法所能处理问题的范围。实例的构建采用面向对象的知识表达方式，将与对象有关的信息以一定的形式封装在对象内部，实例法可以有效地解决数学模型尚难以建立的一类冲突问题，并且随着实例的不断增多，该方法解决问题的能力也将不断加强。为了实现规则的推理机制，需要针对不同种类的冲突类型，建立相应的冲突解决规则，并且添加到规则库中，规则的合理性应经过实践的考验。当发生冲突时，需要针对不同的情况，从规则库中选取适当的规则集，在规则的指导下，有步骤、有目的地解决冲突。
基于优化的冲突解决方法是首先建立冲突模型，设计反映冲突严重程度的指标，并针对该指标利用基因算法进行优化求解。在这里需要明确的是，并非所有的工程设计指标都可以满足，这也是冲突的含义之一。在并行设计环境中，每个设计人员都有潜在的倾向将自己负责的参数限制在比较有利的位置，但这并不是说设计区间就完全不能改变，当某一设计区间做较小的修改时，虽然此时可能将自己的参数设计置于不利的位置，但如果该变量的取值范围已经成为并行设计解决冲突的“瓶颈”，这时就有必要考虑牺牲一个或几个设计区间来达到整体解决冲突的目标，而这种牺牲应该从最不重要的设计参数开始。我们的宗旨在于找到“瓶颈”，解决冲突。
12/11/2004
|
