黄琢华
(建研科技股份有限公司,北京100013)
建筑工程设计需要建筑师﹑结构工程师﹑设备工程师等各个专业的合作,一项完美的设计项目的完成,是设计团队各个成员之间密切协作的结果。在设计过程中,常常需要各专业的设计师面对设计中遇到的各种矛盾和冲突,进行反复协商和修改,并最终取得使用功能﹑建筑外观﹑项目成本﹑施工效率等多种因素综合效果最佳和令业主满意的设计成果。随着建筑规模的加大﹑复杂程度的提高,提高团队协同设计的效率已经成为一种强烈的需求。
目前,一项建筑工程的设计任务,需要应用多个设计软件才能完成。由于各专业软件具有该软件特有的数据结构和输出格式,所以当设计数据在不同的专业软件中进行交流时,常常会造成数据的丢失和畸变。同时,由于各个专业软件没有统一的协同工作平台,使得各专业设计人员之间无法实现设计过程中有效的协同工作。例如,建筑师修改了建筑平面图,结构工程师和其他专业工程师不能实时地得到修改信息,他们还在旧图上继续工作,从而造成了设计时间的浪费。
为此,新一代PKPM软件基于BIM技术,正在开发基于BIM的分布式协同设计平台。本文对协同设计平台的底层框架进行了研究,运用目前先进络开发技术设计了协同平台的多层架构﹑网络架构和不同规模应用的部署方案。
本平台针对建筑设计院的应用特点,运用网络技术和数据库技术实现设计人员的协同设计和信息共享,开发功能实用、技术先进、用户友好的协同设计平台,以提高设计质量和设计效率。本平台基于客户端-服务器架构,为使一个项目的设计团队能够在项目的协同工作中获得灵活性最大、速度最快和数据安全性最高的保证而设计。团队成员在本地计算机上工作,并通过服务器与他们本地的PKPM系统之间有规律地发送和接收项目的修改。
对平台的要求:相对独立,尽量不依附于其他需要付费的商用软件;应符合协同设计技术的发展趋势,采用新的网络技术和数据库技术;应易学易用,无需对用户进行特殊的培训;保证传送过程中数据的安全;有在系统内很方便的团队成员之间发送消息的功能。
主要功能应包括:用户管理;团队管理;BIM模型管理;项目信息管理;图库管理;实时和延迟信息发送机制;数据安全保障机制;进程管理等。
系统应能服务于小型﹑中型﹑大型三种规模的设计院的基于BIM的协同设计工作,特别是对大设计院的大型﹑复杂建筑项目,在项目团队成员之间共享BIM模型时,要使数据传输高效﹑顺畅;同时数据处理应能满足小型﹑中型﹑大型三种规模的建筑工程项目的容量和速度要求。
协同设计平台需要面对异构的网络环境、不同专业的用户需求、复杂的设计业务流程、众多的项目团队组织以及角色分工等问题。因此,如何使协同设计平台及其上层BIM应用软件能够彼此尽量少地受到干扰和牵制,是平台设计中需要解决的重要问题。多层架构技术是解决这一问题的有力途径。在多层架构中,业务逻辑与数据操作及用户交互分离;模块代码相对独立;不同的业务可以分布在系统的不同主机上,也可以将面向不同客户的同一业务分布在不同主机上;数据层与业务层隔离。分层结构的这些特点可以让平台的各部分功能更加明确,减少各层次之间的关联和依赖,提高了软件的开发效率;使软件产品的稳定性、兼容性、扩展性得到提高;减少了数据库遭受错误访问或非法攻击的可能性。因此,基于协同设计平台的需求分析和数据安全性的考虑,本文采用多层架构技术进行平台的系统设计。
本文将协同平台分成界面展现层,业务逻辑层,领域模型层和数据持久层共4个层次。
其中界面展现层主要展现图标﹑对话框﹑数据﹑消息﹑报表﹑图块等系统对用户的提示;回显用户输入的文字﹑数据﹑选项﹑图形元素等;负责系统与用户交互界面的实现。
业务逻辑层主要对应于系统应用层,负责设计业务逻辑的解释与处理;实现协同工作的同步与异步处理;完成用户指定的操作;进行用户请求的业务处理;返回系统对用户请求的处理结果。
领域模型层主要用于将数据持久层提供的数据组织成为具有业务含义的领域模型提供给业务逻辑层使用,数据按照面向对象的方式组织,记录于内存之中。领域模型层的存在使得业务逻辑层无需专注于数据在磁盘上的组织形式与方式。
数据持久层用于所有需要存储的数据的持久化,数据可以包括普通磁盘文件或者数据库。数据库使用ORM(对象关系数据库映射)技术可以避免代码直接操作数据库,增加了系统的可移植性﹑可扩展性和可维护性。持久层是实现项目团队成员间数据共享,保证数据安全性和保密性,以及数据访问正确性的有力保障。
对于协同设计平台,传统的B/S架构﹑C/S架构和SOA架构都是值得考虑的架构方案。
B/S架构(Browser/Server,浏览器/服务器模式),将系统功能实现的核心部分集中到服务器上,客户机上只要安装一个浏览器(Browser)。服务器上安装数据库和应用程序,浏览器通过Web Server同数据库进行数据交互。协同设计平台如果采用B/S架构,则用户端界面只需在Web浏览器中实现就可以了,软件维护只需要针对服务器进行就可以了。但是在这种模式下,一旦出现服务器崩溃现象,其后果非常严重。
C/S架构(Clint/Sever,客户机/服务器模式),将任务合理分配到Client端和Server端来实现,可以充分利用两端硬件环境的优势,降低了系统的通讯开销。C/S架构由于能充分发挥客户端PC机的性能,故有效地减小了服务器的负荷,但是由此带来的代价是需要频繁地对客户端软件进行维护﹑对系统进行升级。同时,如果用户想要在广域网中登录协同设计平台,就必须通过远程的接入或控制,进入局域网环境后才能运行。
SOA架构(service-oriented architecture,面向服务的体系结构)是一个组件模型,它将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义,独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
结合PKPM BIM软件的需求分析,协同设计平台应符合多种不同的客户端需要,从传统客户端,到网页浏览,还需支持移动设备。单一的架构方式并不适用于这样大型的系统。对于设计程序,功能明确,对效率要求高,可以采用C/S架构;对于网页浏览部分,将逻辑代码尽可能放在服务器端,使用B/S架构;对于移动设备的支持,考虑到接口需要支持多种不同的平台,系统和语言,可以采用SOA架构,使用Webservice来实现。
为了使PKPM协同设计平台满足大型﹑中型﹑小型不同规模的设计院的协同设计需求,本文按照这三种规模的设计院的人力﹑工作方式﹑任务规模等特点,设计了三种不同的协同平台部署方案。图1展示的是面对小型设计院的协同平台部署方案。小型设计院的项目通常不太大,项目团队也相对比较小,可能没有专职的CAD管理员和BIM经理,因此面对小型设计院的协同平台部署方案相对简单一些,Web Server﹑BIM Sever﹑Database Server都放在一个服务器里。这样对于小型设计院来说,就可以用较低的设备成本来建设协同设计平台。
图2展示的是面对中型设计院的协同平台部署方案。中型设计院可能有多个独立的项目团队,承担的项目可能大中小规模都有,可能有专职的CAD管理员和BIM经理,也可能是某个设计师兼任BIM经理。中型设计院的协同设计平台中,除了Web Server、BIM Sever、Database Server外还多了 Publishing Server和File Server,而且它们被放在不同的服务器里。
大型设计院的人力﹑财力相对雄厚,承担的项目规模也大,有时还会承担一些特大型工程项目,有专职的CAD管理员和BIM经理。因此为大型设计院设计的协同平台除了中型设计院所有的设备外,还在客户端设置了本地缓存服务器,在多组客户端之间设置了载荷平衡服务器。此外,为适应大型设计院的业务需求,还设置了缓存服务器﹑高性能云计算服务和云存储设备。图3展示了面对大型设计院的协同平台部署方案。
图1 面对小型设计院的协同平台部署方案
图2 面对中型设计院的协同平台部署方案
本文在对协同设计平台进行需求分析,对网络前沿技术进行研究的基础上,结合基于BIM技术的新一代PKPM软件的研发,对协同设计平台的底层框架进行了研究,设计了协同平台的多层架构﹑远程调用框架和不同规模应用的部署方案。该设计提高了软件的可维护性和可扩展性,也提高了软件开发的效率。
图3 面对大型设计院的协同平台部署方案
[1]史美林,向勇,杨光信.计算机支持的协同工作理论与应用[M].北京:电子工业出版社,2000.
[2]于加晴,查建中,陆一平,徐文胜,李楠,M.Sobolewski.面向复杂产品的分布式协同设计系统[J].中南大学学报(自然科学版),2010(2).
[3]高曙明,何发智.分布式协同设计技术综述[J].计算机辅助设计与图形学学报,2004,16(2).
[4] Christos Tjortjis,George Dafoulas,Paul Layzell,etal.A Model for Selecting CSCW Technologies for Distributed Software Maintenance Teams in Virtual Organizations[j].Proceedings of 26th Annual International Computer Software and Applications Conference,2002.
[5] Leandm Navm,Wolfgang Prinz,Tom Rodden.Towards Open CSCW Systems[J].Proceedings of the Third Workshop on Future Trends of Distributed Computing Systems,1992.