基于知識庫的IFC模型存儲技術研究

張越美 高 歌 彭 程 劉 寒 顧 明

(1.清華大學軟件學院，北京 100084； 2.北京信息科學與技術國家研究中心，北京 100084； 3.信息系統(tǒng)安全教育部重點實驗室，北京 100084)

引言

建筑信息模型(Building Information Model， BIM)是建設領域的全周期信息模型。BIM由數(shù)字技術作支撐，在簡化設計流程、計算工程算量、模型交付和檢查、后期運維等方面發(fā)揮了極大的作用[1]。BIM在建筑領域逐漸得到廣泛的應用，buildingSMART組織推行了工業(yè)基礎類(Industry Foundation Classes， IFC)的標準數(shù)據(jù)模型，并被納入ISO標準(ISO16738:2013)，以解決多種BIM設計軟件之間的數(shù)據(jù)交換問題[2]。

隨著建筑設計軟件功能的完善，建筑模型的設計細節(jié)豐富，建模支持的專業(yè)增多，使模型的語義信息增長迅速，導出的IFC模型體積逐漸增大。在實際的工程項目中，單專業(yè)的IFC建筑模型體積已達百兆數(shù)量級，多專業(yè)模型體積接近千兆數(shù)量級。因此，如何高效存儲IFC模型，如何選取IFC存儲的數(shù)據(jù)庫類型以貼合IFC模型的結構，以及如何在IFC模型中建立數(shù)據(jù)字典與數(shù)據(jù)模型的關聯(lián)是IFC模型在土木建筑行業(yè)應用中的挑戰(zhàn)。

1 IFC模型存儲技術類型

1.1 文件系統(tǒng)

文件系統(tǒng)是目前IFC 模型的主要存儲方式。然而，IFC模型中對象的種類、數(shù)量繁多，對象中存在著大量的引用、連接、組合、包含、表示、分配等各類關系。IFC文件中復雜的構件、關系信息被以非結構化信息的方式以構件為單位逐行存儲在IFC文件中，需要全部載入內存才能進行處理與利用。隨著IFC數(shù)據(jù)規(guī)模的增大，帶來了數(shù)據(jù)處理性能與可用性上的嚴重挑戰(zhàn)。

1.2 關系數(shù)據(jù)庫

關系數(shù)據(jù)庫是目前大規(guī)模數(shù)據(jù)表示的重要方式。采用關系型數(shù)據(jù)庫存儲IFC，通常是將IFC Schema轉化實體—關系(ER)模型，為IFC中的各種實體建立數(shù)據(jù)表，以實體內部的屬性作為列，對象之間的關系需要采用外鍵來表示。例如Cruz采用了Oracle 進行 IFC 數(shù)據(jù)存儲，開發(fā)了基于Web的工程管理平臺Active3D[3]。劉照球等基于關系數(shù)據(jù)庫開發(fā)了工程設計模型數(shù)據(jù)庫應用系統(tǒng)[4]。張洋等利用關系數(shù)據(jù)庫SQLServer開發(fā)開發(fā)了基于IFC的信息集成系統(tǒng)[5]。然而，IFC Schema通常較大，如IFC 4x2具有816個不同的實體類型，且實體之間具有非常復雜的關系。因此采用關系數(shù)據(jù)庫存儲IFC，需要建立極為復雜的數(shù)據(jù)表，而且需要進行大量耗時的跨表連接操作才能進行各類復雜查詢。另外，IFC實體的屬性較多，在關系數(shù)據(jù)庫的實際存儲中較為稀疏。此外，由于BIM發(fā)展得較快，IFC標準還在不斷迭代之中，IFC標準版本的變化要求大幅度改動數(shù)據(jù)庫結構，使得數(shù)據(jù)庫維護成本非常高，因此關系數(shù)據(jù)庫不適用于IFC模型的存儲。

1.3 面向對象數(shù)據(jù)庫

IFC模型具備面向對象的特征，針對于這一特性，很多學者提出了面向對象數(shù)據(jù)庫實現(xiàn)對IFC數(shù)據(jù)的存儲。如Tanyer利用面向對象數(shù)據(jù)庫EXPRESS Data Manager存儲IFC數(shù)據(jù)[6]。Farag利用面向對象數(shù)據(jù)庫ObjectStore存儲IFC數(shù)據(jù)并開發(fā)了基于Web的IFC共享環(huán)境[7]。

陸寧等基于SQLServer與Versant分別實現(xiàn)了關系數(shù)據(jù)庫和對象關系數(shù)據(jù)庫的IFC管理系統(tǒng)，并經(jīng)過實驗比較指出面向對象數(shù)據(jù)庫在性能上具有顯著優(yōu)勢[8]。然而，面向對象型的 BIM 數(shù)據(jù)庫本身技術尚不成熟、標準化程度較低，相比于現(xiàn)代的 NoSQL數(shù)據(jù)庫，可擴展性較差。

1.4 NOSQL數(shù)據(jù)庫

NOSQL數(shù)據(jù)庫是無固定表結構、不采用SQL查詢、避免使用連接操作的數(shù)據(jù)庫，通常包括鍵值數(shù)據(jù)庫、文檔數(shù)據(jù)庫、列數(shù)據(jù)庫等，近年來發(fā)展十分迅速。Beetz等基于鍵值型數(shù)據(jù)庫BerkeleyDB開發(fā)了開源BIM服務器BIMserver，提供了模型增量存儲、提取、轉換等功能[9]。林雅虹等人基于文檔數(shù)據(jù)庫MongoDB實現(xiàn)了IFC的存儲并應用在室內路徑規(guī)劃中[10]。Ma等人基于MongoDB開發(fā)了基于Web的BIM協(xié)同協(xié)同，可在線查詢和編輯模型中的對象[11]。余芳強等人基于列數(shù)據(jù)庫Hbase實現(xiàn)了半結構化的數(shù)據(jù)庫，將IFC資源實體的數(shù)據(jù)直接存儲在使用它的可獨立交換實體的記錄中，減少了連接操作，但也增加存儲空間和數(shù)據(jù)冗余[12]。NOSQL數(shù)據(jù)庫通常在查詢速度和擴展性等方面具有一定優(yōu)勢，但其數(shù)據(jù)查詢訪問方式上通常具有一定的局限性，占用的存儲空間也較多。

知識庫(或知識圖譜)是采用網(wǎng)狀的結構對現(xiàn)實世界的事物及其相互關系進行形式化地描述與表達。知識庫通常采用圖數(shù)據(jù)庫進行存儲，通常利于處理大量復雜、互相關聯(lián)的數(shù)據(jù)。并且具有靈活的查詢方式?？梢詾樾畔⒉樵?、專家系統(tǒng)、問答系統(tǒng)等多種應用提供支撐。IFC模型數(shù)據(jù)規(guī)模較大，而且具有近千種對象類型，并且特定構件的表示通常不具有唯一性，而是多種對象互相關聯(lián)表示，與知識庫的特點較為契合。因此，本文采用了知識庫建模的方式，以構件為節(jié)點，構件關系為邊，將IFC模型組織成具有圖結構的知識庫，為開展IFC模型知識庫上的查詢、管理、檢查等應用打下基礎。

2 IFC模型的知識庫構建方法

2.1 知識庫數(shù)據(jù)存儲方法與IFC

知識庫(或知識圖譜)是采用網(wǎng)狀的結構對現(xiàn)實世界的事物及其相互關系進行形式化地描述與表達。知識庫通常采用圖數(shù)據(jù)庫進行存儲，通常利于處理大量復雜、互相關聯(lián)的數(shù)據(jù)。并且具有靈活的查詢方式?？梢詾樾畔⒉樵?、專家系統(tǒng)、問答系統(tǒng)等多種應用提供支撐。IFC模型數(shù)據(jù)規(guī)模較大，而且具有近千種對象類型，并且特定構件的表示通常不具有唯一性，而是多種對象互相關聯(lián)表示，與知識庫的特點較為契合。因此，本文采用了知識庫建模的方式，以構件為節(jié)點，構件關系為邊，將IFC模型組織成具有圖結構的知識庫，為開展IFC模型知識庫上的查詢、管理、檢查等應用打下基礎。

IFC標準的表達主要分為兩個部分：標準SCHEMA的表達和實例模型文件的表達。SCHEMA文件在buildingSMART上以EXPRESS文件的形式定義。EXPRESS是ISO 10303-11中規(guī)定的數(shù)據(jù)模型表示方式。實例模型文件以STEP文件的形式存儲，STEP是ISO 10303-21中規(guī)定的實例數(shù)據(jù)表示方法。本研究中知識庫的生成，將緊密結合IFC的SCHEMA文件與STEP文件標準，解析關鍵語義信息存儲在知識庫中。

在構建知識庫中，本研究選取了圖數(shù)據(jù)庫Neo4j作為IFC模型的存儲介質。圖數(shù)據(jù)庫底層最大限度地貼合圖結構，與圖相關的查詢具有語言簡單、高效的特點，適合表達IFC模型中的復雜關系圖譜。

Neo4j作為圖數(shù)據(jù)庫的代表之一，是第一個使用原生圖數(shù)據(jù)存儲的數(shù)據(jù)庫[13]。在容量方面，社區(qū)版最多支持320億個節(jié)點， 640億個屬性和320億個關系，百兆IFC模型經(jīng)過優(yōu)化后的存儲需要的節(jié)點數(shù)量為十萬級別，因此對于IFC相關模型的存儲完全夠用。在速度方面，由于Neo4j是原生的圖數(shù)據(jù)庫存儲，每個節(jié)點中存儲了每個邊的指針，因此遍歷效率非常高，屬性信息中也可以建立索引，加快屬性查找速度。除了Cypher查詢語言之外，Java平臺有原生的Embedded API可以更高效地完成圖數(shù)據(jù)庫的增刪改查操作，本研究在模型入庫階段即使用了其Embedded API[14]。因此，本文采用Neo4j數(shù)據(jù)庫作為知識庫的載體。

2.2 元數(shù)據(jù)知識的建模存儲

知識庫建立的第一步是對IFC SCHEMA在知識庫中建模、解析存儲。存儲IFC SCHEMA文件的作用有以下幾點：第一，IFC版本眾多，對模型的版本管理尤為重要，知識庫可以驗證模型文件的版本匹配； 第二，對IFC模型使用知識庫建模時，需要依賴SCHEMA知識進行屬性推理。因此，本節(jié)將介紹IFC SCHEMA在知識庫中的建模存儲方法。

如圖1所示，將IFC SCHEMA文件建模存儲為知識庫中的元數(shù)據(jù)知識的步驟分為使用語法分析器ANTRL解析SCHEMA文件、抽取IFC實體信息、補充推理實體屬性信息、屬性類型關聯(lián)、Neo4j數(shù)據(jù)庫儲存。

圖1 元數(shù)據(jù)知識庫建模流程

根據(jù)ANTLR[15]對于Express Schema的解析結果，即可在Neo4j圖數(shù)據(jù)庫中建立元數(shù)據(jù)知識庫。首先，在Neo4j中定義兩個標簽：Node和Attribute，分別代表實例節(jié)點和屬性節(jié)點標簽。實例節(jié)點包含兩個屬性：實體名稱(name)和實體所屬版本(version)，屬性節(jié)點也包含兩個屬性：屬性名稱(name)和屬性下標(index)。其次，在Neo4j中定義了三種關系：HAS_ATTR表示實例節(jié)點具有某個屬性，LINK_TO代表屬性節(jié)點的限定關系，即這個屬性的取值必須是哪一個實體類型，SUBTYPE_OF代表節(jié)點之間的繼承關系。

抽取實體信息后，基于IFC實體之間的繼承屬性，實體的全部屬性應為其父類的全部屬性和自身屬性的并集，因此使用深度優(yōu)先搜索的方法推理出每個實體的完整屬性。最終根據(jù)堆屬性的引用實體類型定義，將每個屬性節(jié)點與相應的引用實體連接，形成完整的元數(shù)據(jù)知識庫模型。

得到了元數(shù)據(jù)知識模型，可以通過可視化工具更為具體地了解不同的IFC版本中的區(qū)別與聯(lián)系，在IFC模型文件的建模過程中進行版本驗證。也可通過簡單的語句對于IFC版本信息進行挖掘和推理。

2.3 實例知識的建模與存儲

知識庫建立的第二步是對IFC實例知識建模存儲。對IFC實例文件的存儲是知識庫的關鍵部分，是在知識庫上查詢、檢查等應用的基礎。在元數(shù)據(jù)知識的基礎下，實例知識的建立分為圖2幾個步驟：IFC文件解析、實體節(jié)點驗證存儲、引用關系建立。

圖2 實例知識庫建模流程

IFC模型文件解析的關鍵點在ANTLR對IFC文件的解析方式，如何建立語法樹來兼顧存儲速度和存儲所占內存大??； 實例節(jié)點驗證存儲的關鍵點在如何通過元數(shù)據(jù)知識庫獲取屬性順序和對應名稱，并在圖數(shù)據(jù)庫中建立索引的方式； 節(jié)點引用關系建立的關鍵點在于引用關系的發(fā)現(xiàn)和建立關系后的關系化簡過程。

實例知識庫建立的第一個關鍵點是：提高IFC模型文件解析速度、減少解析模型占用的內存空間。基于IFC文件解析開源庫實現(xiàn)模型文件的解析有兩點不足，第一，解析方法包含知識庫所不需要的幾何造型重構信息導致解析速度慢； 第二，基于將模型全部解析入計算機內存對存儲空間的開銷巨大。因此，本研究采用ANTLR的Visitor模式，獨立構建實例文件的語法樹，并使用如圖3語法樹拆分算法解決語法樹過大問題。高效對接實例知識庫，極大地提高了實例知識庫建立的時間、空間效率。

圖3 語法樹拆分示意圖

實例知識庫的第二個關鍵點是實例節(jié)點的存儲。在節(jié)點存儲的過程包含三個步驟：實例節(jié)點過濾、實例節(jié)點屬性推理、引用關系建立。IFC實例文件中有大量與語義信息無關的底層幾何信息，底層幾何信息節(jié)點的數(shù)量甚至占整個模型節(jié)點數(shù)量的一半以上。實例節(jié)點過濾的目的即為過濾無語義信息的節(jié)點，節(jié)省實例知識庫空間，提高實例知識庫生成速度。

實例節(jié)點的屬性推理原因是STEP文件中每個實體的屬性列表中是每個屬性的值，沒有屬性的名稱。而在建模過程中，屬性名稱是兩個節(jié)點關系建立時的關系名稱，因此必須通過推理元數(shù)據(jù)知識庫得到屬性對應的名稱。其次，在推理屬性名稱的同時也可以檢查這個模型文件是否符合SCHEMA的基本規(guī)定，例如屬性數(shù)量是否與SCHEMA不對應。屬性對應關系如圖4所示。因此，通過查詢元數(shù)據(jù)只是庫中的屬性名稱，與實例知識庫實體進行匹配，即可推理得到實例節(jié)點的具體屬性鍵值對。最終，單個實例節(jié)點滿足以下原則：第一，節(jié)點的類型標簽為其自身IFC類型及其所有父類類型； 第二，節(jié)點屬性為鍵值對分別對應了IFC SCHEMA中的屬性名和模型文件中的屬性值； 第三，每個節(jié)點加入lineId屬性代表節(jié)點編號，model屬性代表模型名稱。

圖4 屬性推理示意圖

實例節(jié)點存儲后，知識庫中的實例信息只有孤立的頂點，將有關系的節(jié)點連接起來，才能形成真正可推理的知識庫。引用關系的建立分為兩個主要步驟：第一步是逐個遍歷數(shù)據(jù)庫中的每個實例節(jié)點以及其全部屬性，發(fā)掘屬性引用關系后建立有向連接，由引用節(jié)點指向被引用節(jié)點，關系名稱即為屬性名稱； 第二步是對部分引用路徑進行合并精簡，減少不重要的節(jié)點。由于IFC實例文件中的實體的行號為唯一標識，引用關系的設置便以行號為基礎。在使用行號查詢引用節(jié)點時，由于IFC實例文件規(guī)模巨大，往往一個模型包含數(shù)十萬節(jié)點，搜索開銷較大。本文利用圖數(shù)據(jù)庫的索引機制，在節(jié)點存儲時對行號建立索引，極大地降低了查詢的時間開銷。最終，IFC實例文件在知識庫中形成一張巨大的關系網(wǎng)。如圖5可見一個模型中的門(IFCDOOR)節(jié)點在知識庫中的展示。

圖5 IFCDOOR在實例知識庫中的表示

3 IFC知識庫的效率分析

本文所選的測試模型均來自實際的商業(yè)綜合體模型，測試模型有以下三個特點：其一，模型覆蓋了兩種主流IFC版本：IFC2X3和IFC4； 其二，模型涵蓋了建筑、暖通、排水三個專業(yè)，具有多專業(yè)的普適性； 第三，大體量模型的體積超過百兆，使用傳統(tǒng)的內存模型將嚴重受限于用戶計算機的硬件配置，可以更加明顯地體現(xiàn)出知識庫存儲的優(yōu)勢。

表1分析了測試模型載入知識庫的時間效率，效率分析根據(jù)模型載入的幾個重要步驟進行統(tǒng)計，包括：模型文件遞歸下降解析、實體節(jié)點插入知識庫、節(jié)點之間關系建立三個步驟。通過分析可得出以下幾個結論：第一，知識庫建立的總體時間在2分鐘以下，符合工程對于模型存儲的要求； 第二，三個步驟所需時間較為平均，其中模型的解析時間和模型大小呈現(xiàn)正相關，節(jié)點插入時間和關系建立時間和模型內容緊密相關。

表2分析了測試模型在知識庫上查詢的時間效率。我們以構件的存在性簡單查詢語句為例，以上模型需要的查詢初始化用時、單次查詢時間分別如表2所示。

表1 知識庫建立時間效率分析

文件名模型大小(MB)模型解析(ms)節(jié)點插入(ms)關系建立(ms)總時間(ms)綜合體建筑32723 33737 54122 74588 839綜合體暖通17417 95715 75517 25251 622綜合體給排水11016 66218 1494 48343 078

表2 知識庫查詢時間效率分析

文件名模型大小(MB)節(jié)點數(shù)(ms)初始化時間(ms)查詢時間(ms)綜合體建筑327180 39311 758350綜合體暖通174897 9652 255126綜合體給排水110503 4012 33364

此外，我們將本文方法與其它方法存儲過程的內存空間效率進行了對比。其中一種是將IFC解析為語義網(wǎng)三元組，存儲到Jena TDB數(shù)據(jù)庫； 另一種是將IFC實體解析為鏈表，存儲到MongoDB中。如表3所示，在16GB內存計算機的實驗環(huán)境， 300M以上模型的三元組存儲創(chuàng)建過程失敗，而MongoDB的內存占用與模型大小成正比。基于知識庫的模型存儲架構采用逐行解析存儲，內存占用與模型規(guī)模相關性較小，百兆模型的存儲過程占用內存不超過500MB，顯著地提高了內存空間的使用效率。

表3 內存空間效率分析對比

文件名大小(MB)TDB(MB)MongoDB(MB)本文方法(MB)綜合體建筑327失敗13 190434.5綜合體暖通1746 7505 980216.2

4 IFC知識庫的應用

在Neo4j上建立了元數(shù)據(jù)知識庫和實例模型知識庫，即可使用Cypher查詢語言，借助Neo4j可視化平臺，方便快捷地獲取IFC Schema信息和IFC模型信息。

4.1 IFC SCHEMA版本關系查詢

在知識庫的建立章節(jié)，本文介紹了將IFC SCHEMA文件建模存儲入知識庫形成元數(shù)據(jù)知識的方法。隨著BIM的發(fā)展和應用，IFC版本的也做出配合的更新，將版本信息化為結構化的知識，可以方便地查詢IFC版本之間的關系和差異。如下Cypher腳本即可將知識庫中的IFC4X1版本信息與IFC4版本信息做比對，查詢出IFC4X1中的增加元素和相關屬性。

MATCH(m:Entity { ifctype:‘IFC4′})WITH COLLECT(distinct m.name)as ifcnamesMATCH(n:Entity { ifctype:‘IFC4X1′ }),WHERE n.name NOt in ifcnamesRETURN n

4.2 類型繼承關系查詢

Cypher查詢語句在關系查詢上的模糊查詢功能，對于圖數(shù)據(jù)庫的查詢產(chǎn)生極大便利。在IFC SCHEMA定義的數(shù)據(jù)模型中，繼承關系網(wǎng)較為復雜。獲取一個實體的所有子類在官方文檔上查詢費時費力，在文檔類型的數(shù)據(jù)庫上的查詢語言復雜，學習成本較高。而在圖數(shù)據(jù)庫上，通過Cypher語句對于不定長關系鏈的語言設置和圖數(shù)據(jù)庫的底層存儲機制，使相關查詢語句易于理解和書寫，查詢速度快。如下簡單的Cypher腳本即可查詢IfcBuildingElement實體的子類。

MATCH(:Node { name:′IfcBuildingElement′, version:′IFC4′})<-[:SUBTYPE_OF?1..5]-(m:Node)RETURN m.name

如圖6在Neo4j平臺的可視化展示，可以簡潔明了地分析出IfcBuildingElement實體的繼承關系網(wǎng)絡。

圖6 IFC繼承關系可視化

4.3 建筑空間結構查詢

IFC模型中使用IfcSpace實體表示建筑中的空間概念，一個樓層的房間聯(lián)通關系在IFC文件中使用BoundedBy關系表示，在傳統(tǒng)的存儲方式中，空間聯(lián)通關系的查詢難以直觀顯示，而圖數(shù)據(jù)庫對于拓撲關系的表達高效清晰，如下Cypher語句通過獲取門和空間的關系形成圖7所示的建筑的空間關系網(wǎng)絡，快捷地獲取樓層空間結構。

MATCH p=(n:IfcDoor)-[r:isBoundedBy]->(m:Ifc-Space)RETURN p

圖7 實例知識空間關系可視化

5 討論與總結

隨著BIM技術的發(fā)展，IFC作為BIM國際交換標準的普及率逐漸增加，IFC模型的規(guī)模增大、語義信息復雜，IFC模型的存儲是IFC模型查詢的基礎，IFC模型的存儲方案研究關系著IFC模型相關應用的便捷性和高效性。本文介紹了基于知識庫的IFC模型存儲方案和基于知識庫的IFC模型查詢應用。在IFC知識庫的建立中，本文分別實現(xiàn)了以IFC Schema建模為基礎的元知識庫建模、以IFC模型文件為基礎的實例知識庫建模。元數(shù)據(jù)庫的建模為實例知識庫的建立打下基礎，實例知識庫為IFC查詢提供直接依據(jù)。

本文提出的基于知識庫的IFC存儲技術，與文件系統(tǒng)相比，模型不用全部加載到內存，提高了模型信息訪問的效率以及對大模型的支持。與基于關系型數(shù)據(jù)庫存儲技術相比，關系型數(shù)據(jù)庫需要定義明確的表結構以及進行很多跨表操作。而IFC的復雜數(shù)據(jù)模型、稀疏的屬性以及豐富的關系導致建立與維護表結構是困難的，跨表操作是低效的。與面向對象數(shù)據(jù)庫相比，知識庫方案所采用的圖數(shù)據(jù)庫技術更加成熟，成本更低。以MongoDB為代表的文檔類數(shù)據(jù)庫是以JSON格式為基礎存儲數(shù)據(jù)，不受表結構的限制，但存在難以完全表示IFC模型的圖結構信息的缺點。而本文提出的存儲方法可以完善地表示IFC模型中的圖結構信息，并提供了更加靈活的查詢方法。相較于其他圖數(shù)據(jù)庫的存儲方案(如ifcOWL)[16]，本文采用屬性標簽圖對IFC在圖數(shù)據(jù)庫中直接存儲，不需將IFC模型轉換成更復雜圖結構，提高了存儲效率。并通過元數(shù)據(jù)知識庫實現(xiàn)了Schema的動態(tài)綁定，使模型存儲不受制于IFC版本實現(xiàn)。在基于知識庫的應用方面，本文主要基于Cypher語言對模型進行查詢與可視化。相較于SPARQL[17]、SHACL[18]等固定路徑的查詢語言，基于知識庫的方法具有自適應、不需指定匹配路由或路徑長度的特性。該方法一方面良好地適配了IFC數(shù)據(jù)關系復雜、對象的表示方式多樣化的特點，另一方面顯著降低了用戶的查詢難度，使用戶只需關注查詢的目標，而不用關心查詢的實現(xiàn)方式。

本文以IFC版本查詢、類型繼承關系查詢、建筑空間結構查詢等功能為例說明了基于知識庫的IFC查詢的靈活、高效性。在本文構建的IFC知識庫的基礎上，可以利用簡潔靈活的語句實現(xiàn)更復雜的信息查詢，為進一步基于知識庫進行模型檢查、模型提取等應用打下良好的基礎。