基于BIM子模型的分布式版本控制研究

，， ，2

(1.浙江理工大學(xué)信息學(xué)院，杭州 310018;2.嘉興國電通新能源科技有限公司，浙江 嘉興 314000)

0 引 言

建筑信息模型(Building information modeling，BIM)是以建筑工程項目的相關(guān)數(shù)據(jù)為模型基礎(chǔ)模擬建筑物真實信息的數(shù)字化模型[1]。它能將建筑生命周期不同階段的資源、數(shù)據(jù)相互關(guān)聯(lián)，可供不同參與方共同使用[2-5]。在BIM項目的不同階段，由于協(xié)同設(shè)計過程中的多方人員參與設(shè)計需共用同一個BIM模型，這會導(dǎo)致對象模型的不一致性及反復(fù)性問題[6]。同時，由于各個BIM項目參與方通常關(guān)注的是BIM模型中的部分信息，如電氣設(shè)計人員主要在電氣設(shè)計子模型上進(jìn)行工作，因而他們主要關(guān)注電氣設(shè)計子模型。如何有效地支持符合參與方需求子模型的修改和追蹤，是目前BIM協(xié)同工作平臺亟待解決的問題之一。

工業(yè)基礎(chǔ)分類(Industry foundation classes，IFC)是BIM數(shù)據(jù)共享和描述的國際標(biāo)準(zhǔn)[7-9]，目前主流的BIM平臺主要基于IFC標(biāo)準(zhǔn)，如IFC Web Server[10]、XBIM[11]等。IFC Web Server、XBIM主要提供對IFC數(shù)據(jù)處理、瀏覽展示以及對模型數(shù)據(jù)的分析功能。Chen等[12]構(gòu)建了一個BIM數(shù)據(jù)服務(wù)器，通過構(gòu)建針對建筑設(shè)計和結(jié)構(gòu)設(shè)計不同需求的數(shù)據(jù)視圖，實現(xiàn)建筑設(shè)計和結(jié)構(gòu)設(shè)計的協(xié)同工作。但是這些平臺通常不支持模型的版本管理功能。在模型的版本管理上，BIMServer[13]是目前最為廣泛使用的開源BIM平臺，對于模型的管理提供了版本比較功能，然而它并不能很好地跟蹤用戶的修改，也不支持分布式的子模型的設(shè)計模式。商業(yè)軟件一般提供了較強的協(xié)同設(shè)計支持，如：Autodesk Revit?提供了“鏈接模型”和“工作集”兩種模式來支撐協(xié)同工作，Autodesk Vault?提供了對版本控制的支持。然而，這些工具采用集中式的模型管理，并未提供適應(yīng)不同設(shè)計方的領(lǐng)域相關(guān)子模型支持。因此，不同參與方常常需要存儲和傳輸非必要數(shù)據(jù)，由此帶來不必要的存儲、傳輸和解析開銷。

常見的版本管理系統(tǒng)如Git[14]、CVS[15]等，多是基于文件系統(tǒng)的管理方式，是以文本中行數(shù)據(jù)作為數(shù)據(jù)單元，因而不能有效解析IFC這類面向?qū)ο蟮腂IM模型。當(dāng)IFC對象變化時，常常涉及到大量行數(shù)據(jù)變化，這給Git修改跟蹤帶來了許多問題。并且，IFC項目模型常常較大(通常有上百兆)，當(dāng)模型規(guī)模增大時，Git版本跟蹤性能急劇下降。盡管Git實現(xiàn)了分布式的版本控制功能，但是其基于文本管理方案并不能很好地支持基于對象的IFC模型的版本管理。

針對上述問題，本文在已有子模型抽取研究[16]的基礎(chǔ)上，提出了基于領(lǐng)域相關(guān)子模型的分布式版本控制框架，以實現(xiàn)分布式的系統(tǒng)管理。本文的貢獻(xiàn)主要有：設(shè)計了基于操作跟蹤的本地化版本管理機制，以有效記錄用戶對模型修改；在分布式模型管理上，提出了局部更新全局協(xié)同的工作模式，在保證模型一致性的同時，實現(xiàn)了分布式子模型與全局模型的高效同步。

1 分布式子模型版本控制框架

在建筑設(shè)計過程中，由于建筑規(guī)模的擴大及涉及領(lǐng)域的增多，模型數(shù)據(jù)量不斷增加。在版本控制支持上，目前的BIM協(xié)同工作平臺多采用集中式版本控制模式，各設(shè)計人員在完整模型數(shù)據(jù)的基礎(chǔ)上進(jìn)行工作。隨著BIM模型數(shù)據(jù)量的增加，集中式版本控制對網(wǎng)絡(luò)要求越來越高，服務(wù)器壓力也不斷增長。而在建筑設(shè)計過程中，各領(lǐng)域設(shè)計人員主要工作集中于其領(lǐng)域相關(guān)的部分?jǐn)?shù)據(jù)，因此無篩選地獲取全局模型，導(dǎo)致模型數(shù)據(jù)價值密度較低，并且?guī)聿槐匾馁Y源開銷以及相應(yīng)的模型數(shù)據(jù)安全問題[17]。因此，如何為不同領(lǐng)域的參與方提供定制化模型的數(shù)據(jù)，并使得不同用戶能夠在定制化模型上工作，成為提高模型數(shù)據(jù)價值密度的有效解決方案之一。此外，集中式的模型管理較難適應(yīng)分布式的模型開發(fā)，也對數(shù)據(jù)的安全和隱私控制帶來了一定的難度。

為解決上述問題，本文提出了基于操作追蹤的分布式子模型版本控制的設(shè)計框架，如圖1所示。與傳統(tǒng)的集中式管理模式不同之處在于，本協(xié)同設(shè)計框架的數(shù)據(jù)模型分為2層：傳統(tǒng)集中式的數(shù)據(jù)中心全局模型層和相互耦合的領(lǐng)域子模型構(gòu)成的子模型層。設(shè)計人員不再直接修改全局模型，而是在基于由獨立子模型耦合組成的協(xié)同工作網(wǎng)絡(luò)中操作。在該框架中，全局模型層和子模型層同時提供對應(yīng)的版本控制支持，用戶的修改信息在提交到子模型中后，可以同步到全局不同版本中。不同領(lǐng)域設(shè)計人員在協(xié)同工作中通過實現(xiàn)對子模型的版本控制，領(lǐng)域子模型與全局模型的數(shù)據(jù)合并實現(xiàn)全局模型的更新，從而實現(xiàn)局部更新全局協(xié)同的工作模式。

圖1 分布式子模型版本管理的協(xié)同設(shè)計框架

協(xié)同工作過程中，多領(lǐng)域子模型之間數(shù)據(jù)通常存在重疊，因設(shè)計需求不同，各設(shè)計人員對于模型數(shù)據(jù)同時進(jìn)行修改，這導(dǎo)致在各子模型之間以及子模型與全局模型之間，數(shù)據(jù)合并時可能出現(xiàn)數(shù)據(jù)沖突問題，因此需對設(shè)計過程中版本數(shù)據(jù)沖突進(jìn)行消解。如圖1右側(cè)所示，本框架使用基于設(shè)計人員優(yōu)先級的沖突消解方案，實現(xiàn)版本數(shù)據(jù)的合并、統(tǒng)一。

2 基于操作追蹤的版本控制

與傳統(tǒng)基于版本比較的實現(xiàn)方案不同，本框架實現(xiàn)操作行為與操作數(shù)據(jù)實體的轉(zhuǎn)換、引入操作追蹤機制以記錄用戶對模型的修改，幫助各領(lǐng)域參與方記錄BIM模型設(shè)計過程中的操作。通過對操作序列進(jìn)行版本控制，與領(lǐng)域子模型數(shù)據(jù)疊加從而實現(xiàn)版本演變。通過維護(hù)多領(lǐng)域子模型與全局模型數(shù)據(jù)統(tǒng)一，實現(xiàn)局部更新全局協(xié)同的分布式子模型版本控制。

2.1 操作記錄定義

為實現(xiàn)操作追蹤，需記錄設(shè)計人員對模型的操作行為，因此需對設(shè)計人員操作行為進(jìn)行數(shù)據(jù)實體轉(zhuǎn)換。操作記錄實體依據(jù)時間記錄設(shè)計人員對模型實體屬性的修改，記錄主要包括操作符、被操作實體ID以及實體屬性的修改內(nèi)容，版本區(qū)存儲示例如圖2所示。

圖2 版本區(qū)存儲示例

其中操作記錄示例包含內(nèi)容為：

a) 操作ID(Oid)：為保證操作記錄等數(shù)據(jù)唯一性，數(shù)據(jù)存儲過程中添加全局唯一標(biāo)識符(Globally unique identifier,GUID)，作為操作的標(biāo)識符。GUID為二進(jìn)制長度為128位的全局唯一數(shù)字標(biāo)識符。圖2顯示的操作記錄示例，可以看出操作ID “e7f5c016-b7c9-4d48-9569-e57c451c72ad”。

b) 被操作實體ID(OperateOid)：標(biāo)識設(shè)計人員對模型進(jìn)行修改實體ID，該實體ID是其在IFC模型中的全局唯一標(biāo)識，以確保實體ID與模型中實體的映射關(guān)系。圖2示例中，被操作實體為66285。

c) 操作符(Type)：表示設(shè)計人員該操作記錄中的操作屬性，包括實體修改、增加及刪除3種類型。圖2示例中，操作符為Add。

d) 優(yōu)先級(Priority)：用于區(qū)分設(shè)計人員對模型修改的權(quán)限。圖2示例中，優(yōu)先級為2。

e) 時間戳(Time)：記錄設(shè)計人員對模型修改的時間。圖2示例中，時間戳為1480331991252。

本文對操作追蹤定義為：通過完整記錄設(shè)計人員對BIM模型實體的操作，將操作以數(shù)據(jù)實體的方式存儲于版本庫中，實現(xiàn)對設(shè)計人員操作的追蹤。構(gòu)建的版本控制系統(tǒng)實現(xiàn)模型版本控制依賴于模型數(shù)據(jù)與版本數(shù)據(jù)的合并，模型數(shù)據(jù)獨立于版本庫存儲，只存儲原始的模型數(shù)據(jù)，如版本發(fā)生更改時，只需將版本庫中所需版本操作記錄提取，累加到模型數(shù)據(jù)中，即可得到所需的模型版本。該種方式有利于提高模型數(shù)據(jù)傳輸效率。

2.2 版本記錄存儲

為了實現(xiàn)有效的模型版本控制，必須對用戶的修改進(jìn)行合理的記錄、存儲。這里的版本由兩部分組成：模型數(shù)據(jù)和版本數(shù)據(jù)。

模型數(shù)據(jù)包含BIM模型的數(shù)字化描述信息，版本數(shù)據(jù)包含版本修訂情況及設(shè)計人員的操作序列等信息。在模型數(shù)據(jù)中：全局模型包含BIM模型的所有模型信息及全局的版本信息，是協(xié)同工作中數(shù)據(jù)總集；子模型中模型數(shù)據(jù)由全局模型依據(jù)領(lǐng)域需求抽取獲得，用以實現(xiàn)領(lǐng)域中協(xié)同工作。私有庫與領(lǐng)域子模型數(shù)據(jù)一致，用于存儲設(shè)計人員私有版本，實現(xiàn)本地化版本控制。子模型數(shù)據(jù)和全局模型之間為松散同步，按照需求同步而非實時同步，從而降低數(shù)據(jù)傳輸量，提高版本管理效率。

版本數(shù)據(jù)分2部分組成，版本描述信息及操作序列。版本描述信息包括：版本編號、設(shè)計人員ID、優(yōu)先級、時間戳等。其中版本編號為記錄設(shè)計人員提交版本次數(shù)的編號，為版本查詢提供簡明的描述。版本區(qū)除記錄版本內(nèi)容外，同時記錄版本區(qū)當(dāng)前存儲版本數(shù)量、版本總數(shù)量、最新版本號等版本區(qū)信息，如圖2所示。版本總數(shù)量是指設(shè)計人員在最初版本至當(dāng)前最新版本存儲的全部版本的數(shù)量，版本區(qū)當(dāng)前存儲數(shù)量與版本總數(shù)量并不相等，當(dāng)設(shè)計人員對模型版本進(jìn)行回溯操作時，版本管理會將需求版本之后的版本數(shù)據(jù)存儲提取到緩沖區(qū)中，該操作會改變版本區(qū)中當(dāng)前版本數(shù)量。

2.3 版本庫設(shè)計

本文中為實現(xiàn)基于操作追蹤的版本控制，需記錄并階段性存儲領(lǐng)域人員在設(shè)計過程中的操作記錄，因此設(shè)計操作區(qū)用于臨時存儲設(shè)計人員操作序列，設(shè)計版本區(qū)存儲版本信息，為版本控制提供數(shù)據(jù)支持。設(shè)計人員在進(jìn)行版本回溯，版本區(qū)會丟失部分版本數(shù)據(jù)，因此設(shè)計緩沖區(qū)保存丟失版本數(shù)據(jù)，保持?jǐn)?shù)據(jù)完整性。為提高模型數(shù)據(jù)加載效率，保存當(dāng)前版本快照，所以設(shè)計快照區(qū)。版本庫設(shè)計的具體內(nèi)容為：

a) 操作區(qū)：用于記錄設(shè)計人員在新版本提交之前對當(dāng)前模型文件進(jìn)行的所有操作數(shù)據(jù)，當(dāng)新版本成功提交、存儲后，自動清空操作區(qū)。

b) 版本區(qū)：用于記錄提交的完整版本記錄，其內(nèi)容包括設(shè)計人員即提交者對于版本記錄的描述信息，以及對IFC文件中實體修改的記錄信息。

c) 快照區(qū)：用于存儲當(dāng)前模型版本數(shù)據(jù)，由版本區(qū)中初始版本至當(dāng)前版本的操作記錄合并獲得。

d) 緩沖區(qū)：用于存儲回溯版本后丟失的版本數(shù)據(jù)，如設(shè)計人員回溯到歷史版本，則將需求版本與回溯前版本之間版本差異存儲于緩沖區(qū)中。緩沖區(qū)僅在設(shè)計人員進(jìn)行版本回溯后出現(xiàn)。

在工作過程中，版本控制數(shù)據(jù)流如圖3所示。當(dāng)設(shè)計人員完成該階段工作后發(fā)出提交版本請求，服務(wù)器將操作區(qū)中所存操作序列提交到私有庫版本區(qū)中，同時添加設(shè)計人員信息、版本號等版本描述信息。版本提交成功之后服務(wù)器將快照區(qū)數(shù)據(jù)置為當(dāng)前版本，并清空私有庫操作區(qū)，從而實現(xiàn)版本更新。

圖3 版本控制數(shù)據(jù)流圖

本文中版本回溯是指通過對當(dāng)前模型版本進(jìn)行操作記錄的逆操作，回溯至需求版本。逆操作指某一操作與其逆操作疊加后屬于無效操作，如對模型某一實體進(jìn)行刪除，操作記錄中操作符為Delete，其逆操作操作記錄的操作符將更改為Add。

設(shè)計人員請求版本回溯時，將版本區(qū)中當(dāng)前版本與需求版本之間版本數(shù)據(jù)提取到緩沖區(qū)中，并更新快照區(qū)，實現(xiàn)版本回溯。版本前進(jìn)時會讀取緩沖區(qū)中版本數(shù)據(jù)加載至版本區(qū)，對版本區(qū)數(shù)據(jù)重新疊加更新至快照區(qū)，與子模型數(shù)據(jù)整合得到設(shè)計人員的需求模型版本。

2.4 子模型與全局模型協(xié)同

在本文構(gòu)建分布式子模型版本控制框架中，同時支持在全局模型層和子模型層的版本控制，全局模型層的版本控制機制與子模型層版本控制機制一致。

在BIM協(xié)同工作中，由全局模型抽取獲得多個領(lǐng)域子模型，抽取過程中同時抽取子模型中相關(guān)引用數(shù)據(jù)，以保證子模型的完備性，抽取的多個子模型間允許存在交集。[16]圖4為版本同步流程圖，設(shè)計人員在客戶端對子模型進(jìn)行版本控制，存儲于子模型版本數(shù)據(jù)庫，實現(xiàn)該領(lǐng)域設(shè)計人員的版本協(xié)同。

當(dāng)模型版本更新時向服務(wù)器版本庫進(jìn)行推送，服務(wù)器檢測客戶端模型版本庫與服務(wù)器版本庫差異，若服務(wù)器版本庫中數(shù)據(jù)為客戶端數(shù)據(jù)的子集，則依據(jù)時間戳將產(chǎn)生的增量版本數(shù)據(jù)追加到服務(wù)器版本庫中；若客戶端模型版本提交時，服務(wù)器版本庫中存在新的提交記錄，則需要拉取最新版本后進(jìn)行版本提交?？蛻舳讼蚍?wù)器拉取版本數(shù)據(jù)機制與版本推送機制類似，通過比對客戶端版本庫與服務(wù)器版本庫差異，對子模型版本庫推送增量版本數(shù)據(jù)。類似于領(lǐng)域設(shè)計人員版本協(xié)同，領(lǐng)域子模型版本庫與全局模型版本庫進(jìn)行數(shù)據(jù)同步，實現(xiàn)領(lǐng)域子模型與全局模型協(xié)同。

圖4 分布式模型版本同步流程

在版本推送與拉取過程中，可能存在多個子模型中對交集實體的沖突操作，產(chǎn)生版本數(shù)據(jù)沖突，所以需對版本沖突消解后才可完成版本推送與拉取。本文采用基于操作記錄優(yōu)先級及領(lǐng)域相關(guān)度的沖突消解策略。在多個子模型版本協(xié)同工作過程中，如合并的版本數(shù)據(jù)中不存在重復(fù)的被操作實體ID，則依照時間戳順序合并操作記錄；若合并過程產(chǎn)生數(shù)據(jù)沖突，則對操作記錄優(yōu)先級進(jìn)行判斷，如產(chǎn)生沖突的操作記錄中存在高優(yōu)先級的記錄，則選取較高優(yōu)先級的操作記錄作為沖突消解的處理結(jié)果；若無法根據(jù)優(yōu)先級的方式解決沖突，則依據(jù)領(lǐng)域相關(guān)度交付給領(lǐng)域管理人員進(jìn)行沖突消解。

3 系統(tǒng)實現(xiàn)及分析

3.1 系統(tǒng)架構(gòu)實現(xiàn)

BIMServer是目前最為廣泛使用的基于IFC標(biāo)準(zhǔn)的開源BIM服務(wù)器平臺。BIMServer屬于B/S架構(gòu)，維護(hù)和升級方式簡單；支持IFC Engine等多個解析引擎，支持IFC模型的3D展示；使用嵌入式數(shù)據(jù)庫系統(tǒng)BerkeleyDB作為模型存儲，其高效性、可伸縮性切實的適應(yīng)了BIM服務(wù)器對性能上的需求；提供了完整的源碼和SDK，易于擴展。因此本文選擇BIMServer作為系統(tǒng)的開發(fā)平臺。

當(dāng)前BIMServer使用Berkeley DB內(nèi)存數(shù)據(jù)庫(鍵值對存儲)來存儲模型數(shù)據(jù)，實現(xiàn)數(shù)據(jù)讀寫速度優(yōu)化。但是其僅支持較為簡單的數(shù)據(jù)記錄，并不適合作為版本管理的數(shù)據(jù)庫。由于XML的跨平臺性和統(tǒng)一性等優(yōu)點，使其適合作為數(shù)據(jù)交換的媒介，同時XML擁有良好的可擴展性以及方便的信息檢索。因此，采用基于XML的模型版本庫實現(xiàn)方式。本文中模型包含2部分?jǐn)?shù)據(jù)，即BerkeleyDB中存儲的模型數(shù)據(jù)及以XML格式存儲的版本數(shù)據(jù)。

同時，由于BIMServer內(nèi)建的Plugin機制只能提供有限的擴展能力，不能很好地支持平臺所需的接口定義[18]，所以構(gòu)建一個獨立的Servlet作為版本控制功能數(shù)據(jù)交互容器，實現(xiàn)對設(shè)計人員操作記錄的傳輸以及版本控制模塊的調(diào)用。由此，系統(tǒng)架構(gòu)的原型設(shè)計圖如圖5所示，該架構(gòu)分為以下2個部分：

a) 模型數(shù)據(jù)的管理和展示，模型數(shù)據(jù)管理主要通過實現(xiàn)重用及封裝BIMServer模塊實現(xiàn)。

b) 版本控制及協(xié)同、添加VersionManage模塊，其數(shù)據(jù)來源依賴于BIMServer，但方法調(diào)用與數(shù)據(jù)存儲獨立于BIMServer。版本控制及協(xié)同模塊獨立于BimServer內(nèi)建的接口，在協(xié)同設(shè)計過程中該模塊從版本庫中讀取版本數(shù)據(jù)，BIMServerService模塊抽取BerkeleyDB中模型數(shù)據(jù)，版本數(shù)據(jù)與模型數(shù)據(jù)整合得到模型版本。

圖5 原型系統(tǒng)框架設(shè)計

3.2 子模型版本管理實現(xiàn)

為實現(xiàn)子模型分布式管理功能，設(shè)計了5類接口：配置項接口、序列化接口、版本控制接口、遠(yuǎn)程交互接口以及沖突消解接口，如圖6所示，其中部分接口信息如下：

a) 配置項接口：包括setConfig等8個接口，用于設(shè)置版本庫路徑、設(shè)計人員及項目ID等信息，以及實現(xiàn)私有庫與中央版本庫轉(zhuǎn)換。

b) 序列化接口：用于實現(xiàn)設(shè)計人員操作記錄與數(shù)據(jù)實體轉(zhuǎn)換，通過CreateOpertion等方法實現(xiàn)操作行為與操作記錄數(shù)據(jù)實體的轉(zhuǎn)換。通過serialize及deSerialize方法對操作記錄對象進(jìn)行序列化，實現(xiàn)數(shù)據(jù)存儲及讀取。

c) 版本控制接口：用于實現(xiàn)本地化版本控制，該類接口實現(xiàn)功能包含：提交操作記錄到操作區(qū)；提交新版本到版本區(qū)；獲取版本、快照等數(shù)據(jù)；更新快照區(qū)；版本前進(jìn)及回溯。

d) 遠(yuǎn)程交互接口：通過讀取版本庫配置文件，實現(xiàn)版本庫數(shù)據(jù)的推送拉取及克隆。

e) 沖突消解接口：實現(xiàn)沖突消解，預(yù)留部分接口，用于添加沖突處理規(guī)則以適用多應(yīng)用場景下的沖突消解。

圖6 分布式子模型版本控制接口

3.3 性能比較

通過本文構(gòu)建的分布式子模型版本控制框架與目前主流的版本管理系統(tǒng)Git進(jìn)行比較。為了衡量系統(tǒng)在不同模型大小下的性能，選取的文件大小在0～100 MB之間，包含0.02、1.44、5.28、10.80、29.60、61.10、95.90 MB等10組IFC模型，來源于GitHub的BIMServer項目。IFC模型的修改對象為模型中的“墻”實體WallStandCase，在其屬性進(jìn)行的修改后，分別使用Git及本文構(gòu)建的版本控制進(jìn)行版本提交，并計算其系統(tǒng)開銷。系統(tǒng)性能記錄選取的指標(biāo)為：版本提交耗時及提交過程中數(shù)據(jù)傳輸量。其中版本提交耗時只記錄Git本地提交耗時。為了防止單次數(shù)據(jù)的波動性，數(shù)據(jù)為對模型的30次操作的平均值?？蛻舳伺渲脼閃indows 10 64位操作系統(tǒng)，CPU型號為i7-3770，8 G內(nèi)存。

由于Git以文本中行數(shù)據(jù)作為數(shù)據(jù)單元，當(dāng)刪除IFC實體屬性時，會改變文件結(jié)構(gòu)，引起大量的版本修訂記錄，導(dǎo)致Git性能下降。圖7顯示，Git版本提交耗時及版本提交傳輸量隨模型的大小和復(fù)雜度呈上升趨勢。由于本文構(gòu)建的版本控制基于設(shè)計人員的操作追蹤，只需記錄該次設(shè)計人員對模型修改的操作記錄，并不存儲模型數(shù)據(jù)，需記錄數(shù)據(jù)數(shù)量遠(yuǎn)小于Git記錄IFC文件版本修改的數(shù)據(jù)信息，因此在模型數(shù)據(jù)量逐漸增大的情況下，性能優(yōu)于Git版本控制。當(dāng)模型文件大小在約為100 MB時，本文構(gòu)建的版本控制平臺提交耗時約為Git提交耗時的4.75%，數(shù)據(jù)量傳輸僅為Git版本傳輸數(shù)據(jù)量的0.1%。仿真結(jié)果表明本平臺在子模型支持、版本響應(yīng)時間、存儲資源占用及網(wǎng)絡(luò)傳輸速度等方面均有明顯的優(yōu)勢。

圖7 與Git在版本提交的性能比較

4 結(jié) 論

本文通過操作追蹤機制實現(xiàn)對IFC模型版本的記錄，并通過該機制實現(xiàn)BIMServer環(huán)境中的分布式子模型版本控制，使得BIM子模型在協(xié)同工作模式下具有更優(yōu)的應(yīng)用效率及應(yīng)用價值。另外，通過使用數(shù)據(jù)量較小、數(shù)據(jù)價值密度更高的子模型實現(xiàn)版本控制，有效地解決BIM協(xié)同工作中模型性能低、模型版本管理困難等問題。

由于系統(tǒng)采用了分布式模型的架構(gòu)，在子模型與全局模型的版本推送、拉取過程中可能會出現(xiàn)模型數(shù)據(jù)不一致問題。目前的系統(tǒng)主要采用了基于操作優(yōu)先級沖突解決方案實現(xiàn)。后續(xù)將研究基于設(shè)計人員特性的沖突消解機制，以更好地體現(xiàn)不同設(shè)計人員在不同類型的子模型中的優(yōu)先級。另外，由于現(xiàn)有的設(shè)計軟件缺乏對于IFC模型的設(shè)計支持，擬研究將Autodesk公司的Revit系列軟件中對建筑模型的編輯功能與BIMServer的模型管理相整合，以實現(xiàn)多終端瀏覽器為客戶端，BIMServer為服務(wù)器，Revit為建筑編輯及版本管理的B/S架構(gòu)的一體化應(yīng)用平臺。

[1] Eastman C, Teicholz P, Sacks R, et al. BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors[M]. New Jersey, US: Wiley Publishing,2008:101-102.

[2] Soibelman L, Sacks R, Akinci B, et al. Preparing civil engineers for international collaboration in construction management[J]. Journal of Professional Issues in Engineering Education & Practice,2011,137(3):141-150.

[3] Son J W, Rojas E M. Understanding collaborative working processes of temporary project teams in large-scale construction projects[C]//Building a Sustainable Future: Proceedings of the 2009 Construction Research Congress,2009:856-865.

[4] 滿慶鵬,李曉東.基于普適計算和BIM的協(xié)同施工方法研究[J].土木工程學(xué)報,2012,45(S2):311-315.

[5] Liu Y, Nederveen S V, Hertogh M. Understanding effects of BIM on collaborative design and construction: An empirical study in China[J]. International Journal of Project Management,2017,35(4):686-698.

[6] 曹健,張友良.協(xié)同設(shè)計的版本管理[J].計算機集成制造系統(tǒng),1998,4(6):16-20.

[7] Liebich T. IFC4: The New Building SMART Standard[EB/OL]. (2003-03-12)[2017-06-05].http://www.buildingsmart-tech.org.

[8] Building SMART International Ltd. IFC Data File Formats and Icons[EB/OL]. (2016-07-15)[2017-02-16]. http://www.buildingsmart-tech.org/specifications/ifc-overview/ifc-overview-summary.

[9] 王勇,張建平,胡振中.建筑施工IFC數(shù)據(jù)描述標(biāo)準(zhǔn)的研究[J].土木建筑工程信息技術(shù),2011(4):9-15.

[10] Ali I. IFC Web Server Project[EB/OL]. (2016-08-07)[2017-02-16]. https://drive.google.com/file/d/0B3P

RiGtq6fseTnhhQjBhNEs0S2c/edit.

[12] Chen P, Cui L, Wan C, et al. Implementation of IFC-based web server for collaborative building design between architects and structural engineers[J]. Automation in Construction,2005,14(1):115-128.

[13] Jiang Y, Ming J, Wu D, et al. BIM server requirements to support the energy efficient building lifecycle[C]//International Conference on Computing in Civil Engineering,2012:365-372.

[14] Loeliger J. Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development[M]. Sebastopol, US: O’Reilly Media,Inc,2009.

[15] Derek Robert Price, Ximbiot. CVS: Concurrent Versions System[EB/OL]. (2015-07-21)[2017-02-16]. http://www.nongnu.org/cvs/.

[16] 桂寧,王楚涵,董彥松,等.基于工業(yè)基礎(chǔ)分類的協(xié)同工作子模型抽取研究[J].工業(yè)建筑,2016,46(8):176-81.

[17] 陳小波.“BIM& 云”管理體系安全研究[J].建筑經(jīng)濟,2013(7):93-96.

[18] 馬智亮,毛娜.基于BIMserver.org開發(fā)網(wǎng)絡(luò)BIM工具軟件[C/OL]//第一屆全國bim學(xué)術(shù)會議,2015.(2005-11-12)[2017-06-05]. https://www.researchgate.net/publication/283716482.