老生常谈论协同：协同的挑战

　　谈到跨地域的协同，大部分技术人员想到的首先就是网络的问题。从20世纪90年代互联网的逐渐兴起和我们国家网络基础条件的不断建设，跨区域的联网的速度不断提升，甚至有些大型企业构建了自己的专网。但是受到硬件条件、网络环境等综合因素的影响，网络延迟甚至是传输掉包几平是无法避免的问题(当然，全光纤网络除外，但是几乎没有任何一个企业能够承受全光纤网络高昂的建设费用和维护费用)。特别在我们国家，由于一些先天性的原因，移动、联通、电信三家均有相互独立的网络，相互之间进行访问的延迟在某些极端情况下甚至可以达到几十秒。在这种情况下，许多企业的技术人员提出的所谓跨区域“实施协同”实际上只在理论上存在可能性。

　　制造业企业中的信息系统之间的相互协同大部分情况下是字符数据的协同(例如ERP系统的各种报表合并业务)，但PLM系统除了字符数据的协同以外，还有各种文档数据、二维工程图样甚至是三维数据模型的协同，一些高端三维CAD软件产生的数据量动辄十几甚至是几十G……PLM系统协同的数据量是ERP系统的几倍甚至是几十倍。在这种情况下，如果不进行一些特殊的处理，常规的网络根本无法承载这么大的数据量传输，因此SIEMENS、PTC都开发了轻量化的数据模型，其目的就是减少数据量，降低协同时对网络的要求。

　　但是事实上，利用了轻量化技术处理后的产品研发数据依然无法完全满足协同研发的需求。其原因就是随着研发能力的不断加强，各种研发数据之间的关联性也变得越来越强，使得在协同链条上的各个企业必须统一“设计语言”才能识别其他企业所产生的数据。这些“设计语言”首先包括编码、文档格式和数据格式。比如A企业使用的Solidworks设计的三维模型，而B企业用的是Pro/ENGINEER，如果不转换成统一的数据格式，则相互的数据无法识别，也难以达到协同的需求。此外，某些设计软件不同的版本之间的相互识别也有一定的差异，比如Word2003如果不安装特殊的组件，无法识别Word2007的数据。一般情况下工具软件的识别是高版本支持低版本，但是也有例外，例如CATIA V5就不识别CATIA V4的数据。

　　“设计语言”不单纯指数据格式或者设计工具，还包括研发数据之间的关系。例如与一个零件模型相关的不仅仅是三维模型文件，还有相关的特征属性信息、结构信息、工艺信息、工装信息、尺寸及公差信息、原材料及供应商信息等，这些信息加在一起才能完整表达一个零部件。这些信息的完善涉及到不同的人、部门甚至是企业，在协同时，只有协同的几方都明确这些信息的关系、位置和书写规范，协同才能顺畅的进行，否则就非常容易陷入到相互指责之中。上个月笔者接触到一个客户抱怨某PLM系统协同不稳定，总是出问题，后来仔细检查后发现，98%以上的司题都是由于技术人员没有按照标准规范填写相应的内容造成的。针对这样的情况，客户强烈要求将这部分的限制放宽松一些，但是他们的协作单位则一致表示反对，因为信息不完整或者信息错误很可能导致其他协作单位的损失，而一旦真的发生了这样的情况，责任是很难界定的。

　　协同的第三个挑战就是数据的组织。一个产品所有数据累积起来可能有几十个G，如果不对这些数据加以区分、标识，一股脑儿地传递给协作单位，那么协作单位只能是无从下手。因为谁都不知道数据模型在哪儿、工艺文件在哪儿，主模型文件是哪个，哪个数据是有效的，哪个是过期的……因此，必须对数据的类别(设计数据、工艺数据和工装数据等)加以区分，同时加上统一的数据标识(命名、代号和版本号等)，只有这样才可能做到让其他协作单位容易识别。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。