本项目来源于与某“机械设计研究所”的合作项目。该所历史上在管理和设计模式上采用传统的层次化垂直结构。但是近年来,随着用户对产品更新换代的要求越来越快、质量要求越来越高,在竞争日益剧烈、外部压力日益增大的形势下,该所在管理模型上重新定位,打破长久以来形成的垂直结构,形成一种趋向于水平集成的业务模型,这就形成了企业重构的趋势,使企业能更专注于自己的业务特长,在产品研发时,能更好地利用国内更先进的技术力量,以实现合作方异地协同设计。
1 合作方的协同设计
该所以某型产品的设计为基础进行转型试点,他们选定3家具有资质的异地设计单位作为合作方(出于保密性要求,本文暂且称为北京方、上海方和广州方,以此来突出在地理位置上的分布性,而不特指该城市),利用地域和知识优势,充分利用当地资源来设计相关部件,而机械设计研究所负责项目的整体设计、系统集成、过程管理和监控等工作。其简化的工作模型,如图1所示:
这个模型被称之为合作方协同设计PCD(Partners Cooperative Design)。为了避免管理方法与业务模式的不匹配,机械设计研究所决定建立一套符合目前这种业务模式的信息系统。该所已经成功地把PDM(Product Data Management,产品数据管理)系统用到本地产品设计管理中,将产品整个设计生命周期内的所有数据,按一定模式加以定义、组织和管理,使产品数据在整个生命周期内保持一致和共享,为企业设计和生产构筑一个并行产品开发和管理的环境。
但是,现有PDM系统是针对当初封闭的管理模式而设计的,无法应对设计变更比较频繁的异地的合作方协调设计环境。因此,该所要求把原来的系统进行扩展,在原有系统上增加合作方协同设计能力,搭建基于互联网的合作方协同沟通平台,使得部件设计合作方能够在早期就介入产品的研发过程,及时获取产品信息和变更通知,并将相关的信息及时反馈到企业,缩短主要设计部门和合作方的沟通时间,提高合作方在新产品设计中的响应能力,实现各方共赢。
PDM系统的开放性,将为实现产品的异地、异构设计提供强大支持。通过合理利用Web Services技术,实现分布式数据源整合,实现数据物理位置的透明性,可以方便地实现对现有系统的二次封装,有效管理各子系统的信息。通过实现工程中设计、制造、测试、维护等职能的综合考虑,使新产品开发更加有序和有效。
2 基于Web Services的PDM系统架构
根据调研的结果,PDM系统整体采用基于Web Services的架构形式有如下优点:
2.1 有利于协调不同的服务领域间的异构数据模型
本PDM系统的合作方协同设计是一些特定领域相关的服务集合,在这个服务领域中所有服务应该采用统一的数据模型进行定义。但是,由于合作方业务的复杂性,数据服务来自不同服务领域,这就使得模型间语义与结构存在巨大差异,而且具有多点服务的特质。采用基于Web Services的PDM系统,将有利于协调不同的服务领域间的异构数据模型。
2.2 便于实现面向服务的集成(SOI)
SOI是使用Web Services进行的集成,通过使用Web Services来解决集成与互操作的问题。本项目的Web Services平台为完成相似项目将需要提供多种选择,必须选择一种标准化的契约(WSDL)来提供服务,利用WSDL可以达到如下目的:
a、适应当前集成项目:改进现有数据模型,以适应当前集成项目。
b、创建新服务:根据服务契约对传统系统进行包装,创建当前系统集成所需要的新服务。
c、跨越不同数据领域边界:定义用于“进行不同数据模型的映射”的数据转换,以便数据能够跨越不同的数据领域边界。
d、实施企业级的服务质量:为Web服务平台配置执行环境,以支持并实施企业级的服务质量。
本项目Web Services所提供的服务,是把各个合作方本身异构的相关数据,通过Web Service中的XML层,转换为通用的XML形式,然后由PDM系统进行数据集成,这样就形成一个在项目内共享的数据总线。在这个过程中,WSDL在服务契约的定义担任了关键角色。这种技术路线的优势在于,各合作方的数据服务是独立而且异构的,采用Web Services技术就能够提供一种快速集成方案,项目将关注共享数据与可重用的服务,而不是专有的集成产品,因此能够更快、更轻松地确保IT投入与企业战略规划保持一致。
在系统中采用XML格式可能会有效率问题,但是,本项目大量的工作是用于合作设计过程控制与管理,产品本身设计过程利用内部原有的处于封闭状态的PDM系统,因此,大部分相关数据的传输速率应该在可接受范围内的。至于少量大型工艺文件,考虑到合作方协同设计主要是在里程碑点上的传输,而不是日常的频繁传输,所以,速率问题不大。
在这个架构中,合作方本身工作模型并没有改变,合作方的Web Service服务器只是为了建立数据总线的通讯,与合作有关的数据将直接保留在本地数据库相应的区中,这个数据区将直接与Web Service服务器有关应用程序相连。其他的数据将与这个服务器绝缘,以保护本地数据的安全。
项目要求与合作协同设计有关的业务,通过瘦GUI Web客户端程序或者浏览器实现人机交互。在设计的初始方案中有4个关键问题需要解决:第一,这个系统如何来处理以协同设计为特征的业务模型工作流:第二,在PDM处理工艺图纸的时候,由于文件体积庞大,需要重点解决文件存放结构与调用方法的问题;第三,互联网上信息传输的不安全性,是设计本身需要重点考虑的问题;第四,Web Services技术如何实现,实现过程中需要处理哪些问题。
设计要求各合作方的Web Service组件只处理与合作项目相关的数据和文件,所有合作方均通过中心服务器使用数据和功能。所有传输数据协议一律采用XML,不需要改变合作方内部的任何工作方式。包括应用层和传输层两个方面的安全机制需要仔细考虑,以保证各方商业秘密的安全性。
3 PDM体系结构设计
3.1 高层体系结构设计
本项目系统设计共分成3个子系统,它们是:
项目管理与过程管理子系统(Project Management and Process Management,PM&PM)。
工程图档与文档管理子系统(Engineering Drawing and Document Management,ED&DM)。
配置管理与变更管理子系统(Configuration Management and Change Management,CM&CM)。
各子系统要求设计成具有独立系统架构的完整系统,为了减少子系统之间的耦合并增加子系统的内聚度,项目设计要求各子系统之间不得直接交互,它们只能通过共享的数据总线(Data Bus)进行交互,从而减少了开发、集成、调试、维护以及后期升级的难度。系统的整体体系结构关系,如图2所示:
系统的数据总线通过Web Services技术来实现,隔离了远程异构数据的物理位置、数据格式等信息,把本地数据和远程数据结合起来,使用者并不需要知道这些远程异构数据源的具体情况。系统还提供了公用的数据格式与交换、缓存和安全机制,提高了模块的可复用性。
系统在设计中采用垂直分层,水平分模块,力争结构清晰。垂直方向基本按照表示层、业务层和持久化3个层次划分,使关注点分离功能分割清晰,而且通过接口分解了模块之间的耦合性,便于系统维护。
在表示层,按垂直方向分离了用户接口组件和用户接口过程组件;在业务层,按照统一的接口对外,水平分离了业务流程、业务组件和业务实体;在持久化层,水平分离了数据访问组件以及服务代理,实现了统一的数据总线机制,使整个体系结构清晰度得以提高。
3.2 子系统体系结构的设计
本系统要求子系统是具有独立体系架构的系统,各子系统之间只能通过数据总线进行交互,这种规定确保了子系统的独立性,下面简要介绍各个子系统的高层体系结构。
3.2.1 项目管理与过程管理子系统(PM&PM)
本子系统需要对项目合作方进行统一无缝的项目管理与监控,所以具备一般PDM系统所不具备的功能。子系统的下层分为模块,也就是独立的业务单元。项目设计规则要求,各模块是独立设计的,模块之间不能直接交互,而只能通过接口用规则的方法交互,项目的这个要求,确保了模块的高内聚与低偶合,也确保了后期的升级和维护成本比较低。该子系统的项层体系结构,如图3所示:
3.3 工程图档与文档管理子系统(ED&DM)
工程图档与文档管理子系统是这个项目的重要部分,也是PDM系统的核心功能,主要用于检索,修改、变更工艺过程中所需要的各类设计文档与图形文档,其中可能还包括三维演示视频文档,本子系统的顶层体系结构,如图4所示:
3.4 配置管理与变更管理子系统(CM&CM)
本子系统主要用于处理整个工程文档的演化与版本控制,其中包括可视化的版本跟踪,企业编码的生成与应用,批次文档的查询与组合,以及产品零部件的配置等重要信息处理。PDM文件处理只有和配置管理系统结合起来,才可能发挥相应的作用,而变更管理是新产品设计与发布的重要一环。本子系统的顶层体系结构,如图5所示:
4 结论
本PDM系统应用Web Services的重要目的是综合各个合作方的数据,通过隔离合作方不相关数据,保证合作方本身内部数据的安全。PDM系统综合各方数据以后,将把这些异构数据转换成统一的数据格式(XML)的信息,便于各方面的应用。由于采用Web Services技术,各种异构数据和异构平台的整合变得可行,就为系统下一步的发展,打下了坚实的基础。
CIO之家 www.ciozj.com 公众号:imciow