基于區塊鏈的建筑信息模型圖紙多人協同創作系統

申玉民，王金龍*，胡殿凱，劉星宇

（1.青島理工大學信息與控制工程學院，山東青島 266525；2.銘數科技（青島）有限公司，山東青島 266041）

0 引言

建筑信息模型（Building Information Modeling，BIM）是一種管理整個建筑生命周期中的基本建筑設計和項目數據的方法［1］。在建筑物整個生命周期中，BIM提供統一的表示、數據框架和組織，可以與各種數據庫集成，簡化文檔管理，可視化分析過程和結果以及提供可持續性分析和仿真［2］。當前，BIM在大型建筑設計、施工、運維的應用越來越廣泛［3-5］。一些大型項目的BIM圖紙由于其復雜性，工作量巨大，往往涉及建筑、結構、設備等多個專業，為了提高效率，這些BIM圖紙的設計往往需要多人協同創作［6］。但是多人協同創作BIM圖紙通常會帶來BIM圖紙版本混亂、版權劃分無準確依據的問題［6-8］。

傳統BIM圖紙的多人協同創作大多是依靠BIM設計軟件Revit中自帶的工作共享或模型鏈接模式實現的［9-10］，但是該方法存在對計算機性能要求高、單向更新的缺點［9］，并且無法記錄和追溯每次創作后的BIM圖紙信息。之后出現了基于Wiki［11］和云服務的多人協同創作系統，但是由于Wiki僅適用于像知識共享［12］或協作學習［13-14］等場景下的文本信息多人協同創作過程，所以無法應用到BIM圖紙的多人協同創作過程中來。云服務應用范圍更加廣泛，可以緩解本地計算機性能對BIM圖紙多人協同創作過程效率的約束，因此研究者提出將云服務與BIM技術結合起來，開發了基于云服務的BIM協同系統［15］，使用云服務器代替本地計算機完成BIM圖紙的計算和協作，同時將每次創作后的BIM圖紙信息存儲到服務器中，解決了傳統BIM圖紙多人協同創作方法存在的計算機性能要求高等問題，但是由于所有數據都存儲在云服務器中，如果被黑客侵入惡意刪除或修改數據會造成嚴重的數據安全問題［16］，雖然可以通過加密、授權等方式避免一些相關問題，但是仍然存在一些安全漏洞未被解決，數據安全無法保證。針對基于云服務的BIM協同系統存在的問題，一些研究者開始嘗試利用區塊鏈解決建筑信息化應用問題［17-20］，區塊鏈具有的去中心化、可追溯以及防篡改等特性可以較好地解決上述BIM圖紙信息記錄、數據安全等問題。Zheng等［21］提出使用區塊鏈記錄單人創作過程中每次創作后的BIM圖紙信息，利用區塊鏈防篡改和可追溯的性質，完整記錄BIM圖紙整個創作過程并且保證了數據的安全性，實現了單人創作BIM圖紙信息的記錄，但是并未考慮多人協同創作BIM圖紙的信息記錄問題。因此，在多人協同創作BIM圖紙的情況下，如何準確、安全地記錄BIM圖紙的創作過程就成為一個亟待解決的問題，這也是保障設計者們的責權利問題的關鍵。

基于上述研究背景和出現的問題，本文對基于區塊鏈的BIM圖紙多人協同創作系統進行了研究，使用區塊鏈技術記錄BIM圖紙整個創作過程，解決了多人協同創作BIM圖紙版本混亂、不易溯源以及存在數據安全風險的問題。實驗結果表明，系統具有良好的性能，能夠滿足和解決BIM圖紙多人協同創作實際應用中的需求和問題。

1 系統架構設計

1.1 系統模型

建筑信息模型（BIM）圖紙通常需要多名設計者同時在一張圖紙上創作，由于對數據泄露、利益沖突、信息濫用的擔憂，當前往往需要嚴格的許可管理［17］。因此，使用聯盟鏈構建基于區塊鏈的BIM圖紙多人協同創作系統。

如圖1所示，本文提出的BIM圖紙多人協同創作系統采用聯盟鏈技術實現，構建的系統模型主要由BIM圖紙設計者和BIM圖紙負責人構成的創作信息記錄鏈，以及BIM圖紙數據庫組成。BIM圖紙設計者加入創作信息記錄鏈需要獲得BIM圖紙負責人的許可，入鏈后BIM圖紙設計者可以通過遠程過程調用（Remote Procedure Call，RPC）協議由已部署的智能合約向創作信息記錄鏈中發送通過解析BIM圖紙構造的BIM圖紙信息并保存，然后將完整BIM圖紙保存到BIM圖紙數據庫中。同時，其他BIM圖紙設計者如果需要創作BIM圖紙，可以從創作信息記錄鏈中獲取圖紙最后一次創作后的唯一BIM圖紙信息并根據該信息在BIM圖紙數據庫中搜索獲取對應的BIM圖紙進行創作。

圖1 本文系統模型Fig.1 The proposed systemmodel

模型中主要包含如下實體。

1）BIM圖紙設計者：各個BIM圖紙設計者各自獨立，和BIM圖紙負責人共同組成創作信息記錄鏈，共同維護鏈上數據，實現數據的分中心化維護。BIM圖紙設計者加入到創作信息記錄鏈中需要獲取BIM圖紙負責人的許可。

2）BIM圖紙負責人：BIM圖紙負責人是BIM圖紙的發起者和所有者，主要負責授權BIM圖紙設計者加入創作信息記錄鏈。

3）BIM圖紙數據庫：用于存儲初始以及每次創作后的BIM圖紙，存儲格式=｛BIM圖紙實體實例信息hash，創作后完整BIM圖紙｝。

本文系統使用聯盟鏈作為BIM圖紙信息的存儲媒介，利用區塊鏈技術保證各設計者用戶上傳的BIM圖紙信息的不可篡改和公開透明，為以后設計者用戶間可能發生的版權糾紛問題提供存證。同時使用設計者用戶私鑰對BIM圖紙信息簽名，進一步降低了多人協同創作BIM圖紙潛在的安全風險。

1.2 系統架構

基于區塊鏈的BIM圖紙多人創作系統架構如圖2所示，包括以下六層結構。

圖2 本文系統架構Fig.2 The proposed system architecture

1）用戶層。包括BIM圖紙設計者和BIM圖紙負責人兩類用戶，BIM圖紙設計者用戶主要完成對BIM圖紙的創作，BIM圖紙負責人用戶是BIM圖紙的所有者和管理者，主要負責為BIM圖紙設計者用戶授權。

2）應用服務層。主要包括針對系統應用場景設計的服務功能。針對用戶操作場景，設計了用戶注冊和初始BIM圖紙上傳功能；針對數字簽名提取驗證場景，設計了BIM圖紙修改權設定和用戶數字簽名提取驗證功能；針對BIM圖紙修改提交場景，設計了修改后BIM圖紙提交以及最新BIM圖紙獲取功能。

3）節點層。包括BIM圖紙設計者用戶節點和BIM圖紙負責人用戶節點兩種類型，一個BIM圖紙設計者用戶節點對應一個BIM圖紙設計者用戶，用戶的各種操作都由節點完成。

4）合約層。主要包括為區塊鏈節點提供相應功能的智能合約。具體來說，用戶注冊合約對應用戶注冊功能；BIM圖紙修改權設定合約對應BIM圖紙修改權設定功能；BIM圖紙最新修改信息獲取合約對應最新BIM圖紙獲取功能；BIM圖紙修改信息上傳合約對應修改后BIM圖紙提交功能；數字簽名驗證合約對應用戶數字簽名提取驗證功能。

5）共識層。采用Kafka共識機制，保證區塊鏈交易能夠快速地在所有區塊鏈節點之間達成一致性共識并上鏈存儲。

6）數據層。主要包括創作信息記錄鏈。創作信息記錄鏈由所有節點共同維護，保證了BIM圖紙信息記錄的公開和透明。

為了方便系統調用，使用fabric-go-sdk封裝合約鏈碼并向系統和用戶暴露接口，具體接口名稱和屬性見表1。

表1 接口名稱和屬性Tab.1 Interfacenamesand attributes

下面將分別介紹系統各個模塊的功能和流程。

1.2.1 用戶操作模塊

本模塊主要實現用戶注冊和初始BIM圖紙上傳兩種功能，具體流程如圖3所示。

圖3 用戶操作模塊流程Fig.3 Flowchart of user operation module

1）用戶注冊。

如圖3虛線所示，BIM圖紙預設設計者用戶User2發起用戶注冊請求，將用戶注冊信息user發送到系統為之分配的用戶節點Pu，調用UserRegister（）接口觸發用戶注冊合約使用橢圓曲線加密算法為用戶生成唯一的公私鑰對，并將用戶注冊信息與公私鑰對綁定，即私鑰=Map［用戶名，用戶密碼］。最后，用戶節點Pu將公私鑰對返回給用戶。

其中，用戶注冊信息user定義如下：

user=｛name，pwd，id_encryption｝

其中name、pwd、id_encryption分別代表用戶名、用戶密碼以及經過SHA1（）函數加密過的用戶身份證號。將身份證號加密是為了防止用戶節點被不法黑客入侵帶來的用戶真實身份信息泄露問題。

2）初始BIM圖紙上傳。

設定BIM圖紙的預設設計者用戶User2已經在系統中進行了用戶注冊。如圖3序號①所示，預設設計者用戶User2發起BIM圖紙初始信息上傳請求，將初始BIM圖紙上傳到對應的用戶節點Pu。隨后用戶節點Pu使用ifcOpenShell解析BIM圖紙，獲取BIM圖紙實體實例信息BIM_main，然后調用PutChangeRecord（）接口觸發BIM圖紙修改信息上傳合約生成BIM圖紙初始信息記錄BIM_init，同時將BIM圖紙初始信息記錄BIM_init打包成交易后共識上鏈，如圖3序號②和③所示。最后用戶節點Pu將初始BIM圖紙上傳到BIM圖紙數據庫中，如圖3序號④所示。

其中，BIM圖紙實體實例信息BIM_main定義如下：

BIM_main=｛GUID，app_name，per，org，action，T，mod_date，mod_user，mod_app｝

其內容依次為BIM圖紙全局唯一標識符（Globally Unique Identifier，GUID）、BIM圖紙創建應用名稱、創建人信息、創建人所屬組織信息、修改狀態、BIM圖紙創建時間戳、修改日期、修改用戶、修改應用。由于某些項目在BIM圖紙創建時未設置等原因，上述某些內容可能為空。

BIM圖紙初始信息記錄BIM_init定義如下：

BIM_init=｛GUID，uploader_name，version，main_hash，uploader_sign，root_hash，T，MRS_hash，uploader_pub｝

具體包括BIM圖紙全局唯一標識符GUID、上傳者用戶名uploader_name、BIM圖紙版本version、BIM圖紙實體實例信息哈希值main_hash、上傳者私鑰簽名uploader_sign、溯源哈希值root_hash、時間戳T、BIM圖紙修改權設定交易哈希值MRS_hash、上傳者公鑰uploader_pub。其中：由于是初始BIM圖紙，所以初始BIM圖紙版本設為1，之后每次上傳BIM圖紙版本默認加1；BIM圖紙修改權設定交易哈希值由下文數字簽名提取驗證模塊調用PutRightRecord（）接口完成BIM圖紙修改權設定合約生成；root_hash表示當前圖紙的上一次修改交易哈希值，該值可以通過交易自帶的GetTxID（）函數獲取，由于這是BIM圖紙的初始信息，所以設定為BIM圖紙修改權設定交易哈希值。

具體實例如圖4所示。原始BIM為一個房屋模型，包括家具、門、窗、墻等組件。用戶User2首先解析初始BIM圖紙得到BIM圖紙實體實例信息BIM_main，然后將其和用戶名一同輸入初始BIM圖紙上傳界面，點擊界面中的上傳按鈕后調用PutChangeRecord（）接口生成BIM圖紙初始信息記錄BIM_init，然后將BIM_init打包成交易后共識上鏈，同時將初始BIM圖紙上傳到BIM圖紙數據庫中。由于是初始圖紙，BIM圖紙實體實例信息中修改狀態action默認為“NOCHANGE”，BIM圖紙初始信息記錄中將溯源哈希root_hash設置為和圖5中BIM圖紙修改權設定交易哈希值MRS_hash相同。

圖4 初始BIM圖紙上傳示意圖Fig.4 Schematic diagram of initial BIM drawing uploading

在本文系統中，修改后BIM圖紙信息被分別存儲在若干個區塊中，區塊包括區塊頭和區塊體兩個部分，區塊頭中包括頭哈希Hash_h、父哈希Hash_pre、時間戳T以及默克爾樹根MT_Root。其中，頭哈希由父哈希和本區塊頭中的其他信息進行哈希運算得到。區塊體中主要存儲BIM圖紙修改記錄BIM_change。

其中，BIM圖紙修改記錄BIM_change定義如下：

BIM_change=｛GUID，modifier_name，version，main_hash，modifier_sign，root_hash，T，MRS_hash，modifier_pub｝

其內容依次為BIM圖紙全局唯一標識符、修改者用戶名、BIM圖紙版本、實體實例信息哈希值、修改者私鑰簽名、溯源哈希值、時間戳、BIM圖紙修改權設定交易哈希值以及修改者公鑰。其中，root_hash表示當前圖紙的上一次修改記錄哈希值，如果這是當前BIM圖紙的第一次修改，則該值設定為BIM圖紙初始信息上傳交易哈希值，該值可以通過交易自帶的GetTxID（）函數獲取。

1.2.2 數字簽名提取驗證模塊

本模塊主要實現用戶數字簽名提取驗證以及BIM圖紙修改權設定兩個功能。系統中的所有用戶操作都需要進行用戶數字簽名驗證，驗證用戶是不是BIM圖紙的預設設計者用戶，從而保證系統的安全性和魯棒性，因此本模塊在系統中非常重要。

1）用戶數字簽名提取驗證。

用戶數字簽名提取驗證功能在系統中是通過觸發數字簽名驗證合約實現的，主要有如下步驟：首先獲取用戶簽名的原數據、用戶私鑰簽名以及用戶公鑰，然后將其傳入數字簽名驗證合約中的verify（）驗證函數使用用戶公鑰解密用戶私鑰簽名得到解密后的明文，和用戶簽名的原數據做對比，如果相同則說明用戶有權利進行操作或者原數據沒有被篡改。

用戶數字簽名提取驗證功能步驟雖然比較簡單，但是對于整個系統很重要，它進一步保證了系統中用戶各類操作的合法性和安全性。

2）BIM圖紙修改權設定。

BIM圖紙預設設計者用戶對應的用戶節點解析完初始BIM圖紙后，調用PutRightRecord（）接口觸發BIM圖紙修改權設定合約根據預先設定的設計者列表，使用列表中設計者的私鑰對BIM圖紙初始信息記錄BIM_init中的全局唯一標識符簽名，從而得到設計者數字簽名列表，然后繼續生成BIM圖紙修改權設定記錄MRS，最后將BIM圖紙修改權設定記錄MRS打包成交易后共識上鏈。

其中，BIM圖紙修改權設定記錄MRS定義如下：

MRS=｛BIM_desc，sign_list，GUID，main_hash，co_desc，T，MRS_hash｝

其 中BIM_desc、sign_list、GUID、main_hash、co_desc、T、MRS_hash分別代表BIM圖紙描述、設計者私鑰簽名列表、BIM圖紙全局唯一標識符、實體實例信息哈希值、設計者公司簡介、時間戳以及此次BIM圖紙修改權設定交易哈希值。

圖5說明了BIM圖紙修改權設定的整個過程，設定圖4中初始BIM圖紙的預設設計者用戶為User1和User2。當用戶User2對應的用戶節點解析完初始BIM圖紙后，將解析得到的初始BIM圖紙實體實例信息和預設用戶名列表輸入BIM圖紙修改權設定界面，點擊界面中的設定按鈕后調用PutRightRecord（）接口使用預設設計者用戶User1和User2的私鑰對BIM圖紙全局唯一標識符簽名并生成設計者私鑰簽名列表sign_list，然后繼續生成BIM圖紙修改權設定記錄MRS，最后將記錄打包成交易共識上鏈存儲。圖4中BIM圖紙初始信息記錄的MRS_hash即為此次BIM圖紙修改權設定記錄中的MRS_hash。

圖5 BIM圖紙修改權設定示意圖Fig.5 Schematic diagram of setting BIM drawingmodification right

1.2.3 BIM圖紙修改提交模塊

為了滿足BIM圖紙頻繁修改的需求，避免BIM圖紙頻繁修改導致的BIM圖紙版本混亂和版權劃分無準確依據等問題，本模塊使用智能合約技術自動檢驗用戶操作合法性，自動記錄合法用戶的修改操作，利用智能合約規范鏈上交易者的行為，有效防止了上述問題的產生。

本模塊主要實現修改后BIM圖紙提交以及最新BIM圖紙獲取兩個功能。模塊完整流程如圖6所示。

圖6 BIM圖紙修改提交模塊流程Fig.6 Flowchart of BIM drawing modification and submission module

1）最新BIM圖紙獲取。

如圖6序號①和②所示，BIM圖紙預設設計者用戶User2發起最新BIM圖紙獲取請求，觸發數字簽名驗證合約驗證當前用戶是否是BIM圖紙的預設修改用戶，如果驗證通過，則繼續進行后面操作，否則拒絕請求并退出。然后，調用QueryChangeRecord（）接口觸發BIM圖紙最新修改信息獲取合約從創作信息記錄鏈上查詢最新BIM圖紙信息hash，即區塊鏈中BIM圖紙最后一次修改記錄中的實體實例信息哈希值，見圖6序號③。隨后，用戶節點Pu將查詢到的最新BIM圖紙信息hash返回給用戶，用戶根據該hash去BIM圖紙數據庫中查找最新BIM圖紙進行創作，如圖6序號④～⑥所示。

2）修改后BIM圖紙提交。

BIM圖紙預設設計者用戶User2在修改完BIM圖紙后，發起BIM圖紙修改信息提交請求。隨后觸發數字簽名驗證合約驗證當前用戶是否是圖紙預設修改用戶，如果驗證通過，則繼續進行后面操作，否則拒絕請求并退出，如圖6下半部分序號（1）和（2）所示。之后，調用PutChangeRecord（）接口觸發BIM圖紙最新修改信息獲取合約查詢當前鏈上最新BIM圖紙修改信息記錄中的BIM圖紙版本并和本地修改前BIM圖紙版本比較，根據比較結果和接口預設規則返回最新BIM圖紙修改信息記錄或NULL，見圖6序號（3）和（4）。如圖6序號（5）～（7）所示，如果返回最新BIM圖紙修改信息記錄則根據記錄從BIM圖紙數據庫中獲取完整BIM圖紙并與本地修改后BIM圖紙使用腳本通過Revit等建模軟件實現BIM圖紙融合，然后使用ifcOpenShell解析融合后BIM圖紙獲得BIM圖紙實體實例信息BIM_main，繼而生成BIM圖紙修改信息記錄BIM_change，之后將BIM_change打包成交易后共識上鏈。最后，用戶節點Pu將融合后的完整BIM圖紙上傳到BIM圖紙數據庫中存儲。

上述流程提到的PutChangeRecord（）接口預設規則如下：

a）如果當前鏈上BIM圖紙版本等于本地修改前BIM圖紙圖紙版本加1，說明本地修改前BIM圖紙圖紙被多位設計者修改，則返回當前鏈上最新BIM圖紙修改信息記錄并獲取完整BIM圖紙與本地修改后BIM圖紙融合，融合后BIM圖紙版本設為本地修改前BIM圖紙版本加1；

b）如果當前鏈上BIM圖紙版本為NULL或小于本地修改前BIM圖紙圖紙版本加1，說明本地修改后BIM圖紙為最新版，則返回NULL，本地修改后BIM圖紙版本設為本地修改前BIM圖紙版本加1；

c）如果當前鏈上BIM圖紙版本大于本地修改前BIM圖紙版本加1，說明本地修改后BIM圖紙前已有多個版本，則返回當前鏈上最新BIM圖紙修改信息記錄并獲取完整BIM圖紙與本地修改后BIM圖紙融合，融合后BIM圖紙版本設為當前鏈上最新BIM圖紙版本加1。

當上傳初始BIM圖紙時，經查詢鏈上最新BIM圖紙版本為NULL，應用接口規則b返回NULL后直接將接口生成的BIM圖紙初始信息記錄和初始BIM圖紙上傳到區塊鏈和BIM圖紙數據庫中，初始BIM圖紙版本號為1。圖7以各版本BIM圖紙鏈上次序為例說明多位BIM圖紙設計者在同一初始版本BIM圖紙的基礎上進行協作修改提交的流程，圖中數字代表BIM圖紙版本號，大寫字母代表BIM圖紙設計者。

圖7 多人協作修改提交示意圖Fig.7 Schematic diagram of multi-person collaborativemodification and submission

下面將對圖7中的多人協作修改提交流程做詳細解釋。

1）A、B、C、D四位設計者同時獲取版本1的初始BIM圖紙進行修改。

2）設計者A首先創作完，首先查看當前鏈中最新BIM圖紙版本號，結果是1，比本地修改前BIM圖紙版本加1要小，根據PutChangeRecord（）接口規則b，將本地修改后BIM圖紙版本設為本地修改前BIM圖紙版本加1后直接上傳到區塊鏈和BIM圖紙數據庫中，記為版本A2。

3）設計者B隨后創作完畢，首先查看當前鏈中最新BIM圖紙版本號，結果是2，和本地修改前BIM圖紙版本加1相同，根據PutChangeRecord（）接口規則a，返回當前鏈上最新BIM圖紙修改信息記錄并獲取完整BIM圖紙與本地修改后BIM圖紙融合，將融合后的BIM圖紙版本設為本地修改前BIM圖紙版本加1后上傳到區塊鏈和BIM圖紙數據庫中，記為版本AB2，此時設計者E獲取版本AB2的BIM圖紙進行創作。

4）設計者E創作完畢，首先查看當前鏈中最新BIM圖紙版本號，結果是2，比本地修改前BIM圖紙版本加1要小，根據PutChangeRecord（）接口規則b，將本地修改后BIM圖紙版本設為本地修改前BIM圖紙版本加1后直接上傳到區塊鏈和BIM圖紙數據庫中，記為版本E3。

5）此時設計者C創作完畢，首先查看當前鏈中最新BIM圖紙版本號，結果是3，比本地修改前BIM圖紙版本加1要大，根據PutChangeRecord（）接口規則c，返回當前鏈上最新BIM圖紙修改信息記錄并獲取完整BIM圖紙與本地修改后BIM圖紙融合，將融合后的BIM圖紙版本設為當前鏈上最新BIM圖紙版本加1后上傳到區塊鏈和BIM圖紙數據庫中，記為版本C4。以上就是圖7中多人協作修改提交流程的詳細解釋，未說明設計者D的修改提交操作和設計者C同理，在此不再贅述，按照此方法上傳修改后BIM圖紙可以較好地解決多人協同創作同一BIM圖紙上傳時帶來的融合或版本控制問題。

BIM圖紙修改提交具體實例如圖8所示，圖中僅展示主要步驟。設定這是圖4中初始BIM圖紙的第一次修改，修改操作為刪除圖紙中的一個家具組件。用戶User2發起BIM圖紙最新信息獲取請求，通過最新BIM圖紙獲取界面調用QueryChangeRecord（）接口從本地區塊鏈中搜索BIM圖紙最新實體實例信息hash，然后根據該hash從BIM圖紙數據庫獲取最新BIM圖紙進行修改，如圖8中序號①和②所示。用戶User2修改完BIM圖紙之后，將修改狀態action設置為“DELETED”，然后發起BIM圖紙修改提交請求，將用戶名和修改后BIM圖紙實體實例信息輸入修改后BIM圖紙提交界面，點擊提交按鈕后調用PutChangeRecord（）接口查詢鏈上最新BIM圖紙版本并和本地修改前BIM圖紙版本加1比較，發現鏈上最新BIM圖紙版本比本地修改前BIM圖紙版本加1要小，根據PutChangeRecord（）接口規則b，將本地修改后的BIM圖紙版本設為本地修改前的BIM圖紙版本加1，然后解析修改后的BIM圖紙獲取BIM圖紙實體實例信息，生成BIM圖紙修改信息記錄BIM_change并打包成交易共識上鏈，如圖8中序號③～⑤所示，最后將修改后的BIM圖紙上傳到BIM圖紙數據庫中。

圖8 BIM圖紙修改提交示意圖Fig.8 Schematic diagram of BIM drawing modification and submission

2 系統測試評估

2.1 系統環境介紹

本文系統基于Hyperledger Fabric1.4框架結合智能合約技術開發實現。本文系統安全機制依靠Fabric成熟的安全機制，選用的共識機制Kafka也是Fabric自帶的共識機制，因此系統安全性得到保障。

2.2 區塊鏈系統性能測試

實驗用設備為兩臺筆記本，兩臺筆記本均為8 GB內存且都使用4核lntel Core i5處理器，每臺筆記本都運行4核2 GB內存的虛擬機兩臺。虛擬機中均搭載Ubuntu18.04系統。Kafka實驗環境共有3個ZooKeeper服務、4個Kafka服務、3個排序節點服務、2個組織。每個組織一個證書頒發機構（Certificate Authority，CA）服務、3個節點，組織1兩個節點，組織2一個節點，每個節點對應一個CouchDB。背書策略設定為每個組織中至少一個背書節點參與背書。

圖9為實驗BIM，包括家具、門、窗以及墻組件。預設修改用戶為User1、User2以及User3，每位用戶對應一個節點，User1和User2屬于組織1，User3屬于組織2。

圖9 實驗BIMFig.9 Experimental BIM

系統性能測試相關指標主要包括：節點提交交易到系統出塊的時間Btime、最長出塊等待時間Btimeout、區塊最大交易數MMCount。其中，Btimeout與MMCount為系統的出塊條件，滿足其中之一的條件即可出塊。

2.2.1 出塊時間測試

針對同時間段內多用戶節點并發交易的場景，進行系統出塊時間測試，測試系統在處理多節點并發交易時，出塊時間是否能夠滿足用戶日常應用。測試環境設定如下：每個組織中的用戶節點都不停地發送1 000條BIM圖紙修改提交交易，測試系統的平均出塊時間是否滿足要求，即小于設定的最大出塊時間。本文按照Fabric聯盟鏈出塊常規設定Btimeout為2 s，本文系統共3個用戶節點，故設定MMCount為3。

一共進行20次測試，每次測試后計算平均出塊時間，結果如圖10所示。由圖10可知，出塊時間一開始呈現上升趨勢，到第9次測試左右到達最大出塊時間，之后圍繞平均出塊時間上下波動，這種結果的原因是隨著測試次數的增加，大量的測試數據占用了較多的系統內存，所以會對系統的性能產生一定影響。經過20次測試，本文系統處理BIM圖紙修改提交交易的平均出塊時間為0.467 85 s，最大時間為0.55 s，遠遠小于設定的最大出塊時間2 s，故實驗的出塊條件為達到區塊最大交易數。實驗結果表明，本文系統能夠完善處理3個節點并發提交的3 000條交易請求，能夠滿足正常系統的應用需求。

圖10 出塊時間Fig.10 Block generation time

2.2.2 系統處理速率測試

針對多用戶并發大量交易請求的場景，進行系統處理速率測試，測試系統在處理多節點并發交易時，系統在保證最大出塊時間內穩定出塊的條件下的處理速率。測試環境設定如下：每個組織中的節點同時發出400、800、1 200、1 600、2000、2400條交易請求，測試系統在保證最大出塊時間內穩定出塊的條件下的處理速率。

測試結果如圖11所示。由圖11可以看出，隨著用戶請求頻率的增加，系統處理速率最初是線性增加的，直到用戶請求頻率達到每秒1 600次交易時，系統處理速率逐漸達到飽和，約為每秒1 568次交易。隨后系統處理速率由于數據量過大占用內存等原因而開始下降。實驗結果表明，系統在保證最大出塊時間內穩定出塊的條件下的最大處理速率為每秒1 568次交易，完全可以滿足用戶日常的正常使用需求以及系統的使用標準。

圖11 系統處理速率Fig.11 System processing rate

3 結語

區塊鏈是一種通過去中心化和去信任化，依靠集體共同維護的數據庫技術，作為近幾年的新興技術已經在各行各業引起了廣泛的關注和研究熱潮。BIM通過數字化手段，將建筑的各種信息整合于一個三維模型信息數據庫中，與區塊鏈技術有很好的契合點。本文結合區塊鏈技術，提出了基于區塊鏈的BIM圖紙多人協同創作系統，將BIM圖紙整個創作過程中的所有創作后BIM圖紙信息上鏈存儲，依靠區塊鏈可追溯、防篡改等特性，解決了BIM圖紙版本混亂、不易溯源以及存在數據安全風險等問題。最后，設計了相關實驗對系統性能進行了測試，測試結果表明系統具有良好的性能，能夠滿足用戶日常需求。本文提出的BIM圖紙多人創作系統可以為后續的版權劃分工作提供依據，后續可以對此展開研究。