賴華輝， 侯 鐵， 鐘祖良， 趙云凡

(1. 深圳市市政設計研究院有限公司， 廣東 深圳 518029， 2. 重慶大學 土木工程學院， 重慶 400045；3. 上海交通大學 船舶海洋與建筑工程學院， 上海 200240)

近年來，BIM(Building Information Modeling)技術及相關軟件已被廣泛應用在國內外建筑領域，以促進建設項目全生命周期過程中各方數據的共享與交換。為規(guī)范建設項目的數據存儲、交互與管理過程，bSI(buildingSMART International，前身為IAI，International Alliance for Interoperability)研究并發(fā)布了建筑領域的一系列標準，如IFC(Industry Foundation Classes)，IDM(Information Delivery Manual)，MVD(Model View Definition)，BCF(BIM Collaboration Format)等。其中，IFC標準是bSI最早研究的數據存儲標準，且一直在更新維護。IFC標準的目的是促進建設項目各方在統(tǒng)一的數據標準基礎上進行有效的數據交互，以實現各業(yè)務應用。現階段，國內外很多學者基于IFC標準開展研究，如能耗分析[1]、GIS數據轉換[2]、算量計價[3]、施工管理[4]等。建筑領域很多軟件也研發(fā)了IFC數據接口，以支持IFC模型數據的輸入與輸出。

然而，盡管學術界和工業(yè)界已開展IFC的研究與應用，但在建設項目實際應用中，基于IFC標準的BIM數據共享與交換過程仍出現數據不一致的問題，如數據丟失、數據失真等。同時，由于建筑從業(yè)人員對IFC標準的認識不足，導致IFC標準對數據交互的作用受到質疑，延緩了IFC標準的深入推廣與應用。特別地，我國政府目前也在大力推廣BIM技術應用，如建質函〔2015〕159號《關于推進建筑信息模型應用的指導意見》，充分了解并準確使用BIM數據標準IFC，對加快推動建筑業(yè)BIM技術深化應用具有重要作用。

鑒于上述原因，本文以IFC標準的發(fā)展歷史為切入點，系統(tǒng)分析IFC標準關于建筑信息的表達，并剖析建筑領域各軟件關于IFC數據的解析問題及其產生原因，進而深入探討IFC標準的未來發(fā)展。通過本文分析與討論，以期使讀者對IFC標準有更清晰的認識，促進IFC標準在建設項目全生命周期過程中的研究與應用。

1 IFC發(fā)展追溯

1.1 提出背景

經過不斷的發(fā)展，IFC標準已成為不同學科和不同軟件之間BIM數據交互的事實標準[5]。BIM技術的概念可追溯至Eastman等[6]在1974年提出的“Building Description System(建筑描述系統(tǒng))”，但限于當時的科學技術水平，并未引起較大關注與影響。到2002年，Laiserin采用Building Information Modeling進行報道[7]，該理念開始被廣泛推廣。同時，隨著BIM軟件廠商的大力宣傳，BIM技術開始被廣泛應用。事實上，IFC標準在BIM技術應用前已被提出。

在二十世紀90年代，建筑領域出現了具有不同功能的軟件，但由于缺乏共同的數據標準，軟件之間的數據共享與交換需要研發(fā)針對性的一對一數據接口，數據交互非常困難。因此，12家美國公司在1994年召開會議，討論制定開放的、公共的數據標準，以實現各軟件之間的數據共享與交換。這12家公司包括Autodesk，ArchiBus，HOK，Primavera等知名企業(yè)[8]，涉及建筑領域的軟硬件、設計、研究、應用等。1997年，上述12家公司共同創(chuàng)立IAI組織，致力于在建筑領域研究開放的、公共的數據標準，以支持建設項目全生命周期各專業(yè)的數據表達與交互。IAI組織的成立促進了IFC標準的研究，并為其可持續(xù)發(fā)展提供了穩(wěn)固的基礎。

1.2 發(fā)展歷程

經過業(yè)界各專家持續(xù)不斷的努力，借鑒STEP標準，IFC標準的第一個版本IFC1.0在1996年12月正式發(fā)布。經過20多年的發(fā)展，最新發(fā)布的IFC版本是IFC4.1，其發(fā)展歷程可見圖1。應注意的是，IFC標準在2005年被正式采納為ISO標準(ISO/PAS 16739: 2005)[9]，肯定了IFC標準在建筑領域數據交互方面的重要作用。

發(fā)展至今，IFC標準不僅在專業(yè)領域范圍，也在數據結構表達與定義方面進行了拓展與優(yōu)化。表1總結了不同IFC版本所包含的實體Entities、類型Types以及屬性集Property sets。其中，IFC 4.1包含801個Entities、400個Types、413個Property sets，囊括建筑、結構、暖通、電氣和施工管理等8個專業(yè)領域。這些數據反映了IFC標準在建筑信息表達方面的豐富性。已有研究表明，IFC標準能較好地描述建筑產品的幾何尺寸[10]、能耗[11]、進度[12]以及成本[13]等信息。

圖1 IFC標準發(fā)展歷程

表1 不同版本的IFC標準組成

版本IFC1.5.1IFC2.0IFC2xIFC2x2 Add1IFC2x3IFC2x3 TC1IFC4IFC4 Add1IFC4 Add2IFC4.1實體 Entities186290370329653653766768776801類型 Types95157229313327327391396397400屬性集 Property sets——83312312317408410413413

2 IFC標準的數據表達研究

IFC標準的語義非常豐富，能夠表達建筑、結構、電氣、暖通、給排水等多專業(yè)，但相應的IFC模型數據結構復雜且數據量大，不利于初學者和建筑從業(yè)人員快速讀懂和有效應用IFC模型數據。因此，有必要分析IFC標準關于建設項目數據表達的基本概念和整體結構。本章主要介紹IFC標準的框架結構、實體數據、模型數據三方面。

2.1 IFC標準框架結構

IFC標準由四個層級組成，分別為資源層(Resource Layer)、核心層(Core Layer)、交互層(Interoperability Layer)和領域層(Domain Layer)。圖2展示了IFC4.1標準的框架結構。應說明的是，圖2是英文版IFC4.1標準框架[14]的中文翻譯結果。資源層描述了建設項目中可重復使用的基本數據，如幾何資源、屬性資源和材料資源等；核心層主要定義了IFC的基本結構、基礎關系和公用概念等；交互層總結了建設項目各專業(yè)的一些通用構件實體；領域層則總結了各專業(yè)的特定構件實體。各層IFC實體之間的引用遵循以下原則：上層實體可引用下層實體，但下層實體不能引用上層實體。在實際應用中，用戶可根據需要調用IFC模型中不同類型的數據。

圖2 IFC4.1標準的框架

2.2 實體的IFC定義

借鑒STEP標準，IFC標準同樣采用形式化的EXPRESS語言作為邏輯規(guī)范的描述。EXPRESS定義了超類(SuperType)和子類(SubType)的概念，建立了IFC實體之間的繼承關系。以柱實體IfcColumn為例，其EXPRESS描述如下。由于大部分軟件支持IFC2x3的解析，本文主要采用IFC2x3標準的相關定義進行解釋說明。

ENTITY IfcColumn

SUBTYPE OF (IfcBuildingElement);

END_ENTITY;

IfcBuildingElement是IfcColumn的超類，對應地，IfcColumn是IfcBuildingElement的子類。IfcColumn繼承了IfcBuildingElement的所有屬性，如圖3所示。通過繼承關系的追溯，IfcColumn的最上層超類實體為IfcRoot。除資源層的實體，實體IfcRoot也是其他所有實體的超類。

圖3 IfcColumn屬性(IFC2x3)

EXPRESS定義的實體屬性有三類：顯式屬性、導出屬性、反向屬性。圖3的實體IfcColumn從超類實體中繼承了26個屬性，其中，8個顯式屬性和18個反向屬性。應說明的是，不同學者可能有不同的屬性名稱定義，如顯式屬性可稱為直接屬性，導出屬性可稱為派生屬性，反向屬性可稱為反屬性、逆向屬性/逆屬性。本文的屬性名稱以GB/T 16656.11-2010[15]為準。在具體的IFC模型文件中，實體的顯式屬性可通過實體本身的實例語句定義，導出屬性需通過既定的計算得到具體值，反向屬性需通過其他實體進行表達。第2.3節(jié)將結合IFC模型文件，分析IFC實體各屬性的具體使用。

2.3 模型的IFC表達

與STEP物理文件相同，IFC模型文件根據ISO 10303-21標準定義，主要分為頭文件和數據文件兩部分。頭文件主要定義IFC模型文件的創(chuàng)建時間、創(chuàng)建軟件和IFC版本等基本信息；而數據文件主要存儲建設項目的各類數據。此處，通過模型文件的IfcColumn實例及相關實例語句分析構件的IFC表達方法，如圖4所示(為便于分析，圖中僅列出部分IFC實例語句)。

圖4 IFC模型文件分析(IFC2x3)

從圖4左側可見，實體IfcColumn的8個顯式屬性通過#240實例語句的8個屬性值進行直接表達。其中，屬性OwnerHistory，ObjectPlacement，Representation通過引用其他語句進行具體的表達。例如，屬性Representation通過實例#237表達幾何外觀。經分析，該構件通過矩形實體IfcRectangleProfileDef描述矩形截面(300 mm× 300 mm)。除實體IfcRectangleProfileDef，可通過其他實體描述相同形狀，如實體IfcArbitraryClosedProfileDef。IFC標準允許采用不同方式表達相同信息[16]。經過分析IFC模型文件，圖4右側繪制了實體IfcColumn反向屬性HasAssociations的關系圖。材料實體IfcMaterial通過實體IfcRelAssociatesMaterial的引用，關聯至實體IfcColumn，描述了屬性HasAssociations的具體信息?？梢?，IFC實體的反向屬性一般通過關聯實體關聯外部信息。

在上述的分析中，IFC模型文件的IFC實例語句與IFC標準的實體定義進行了對應，分析得出建設項目模型的具體表達，可進一步對IFC模型數據進行加工處理。

3 IFC數據交互過程存在的問題

3.1 軟件對IFC標準的驗證情況研究

在建筑領域，很多軟件具有輸入或輸出IFC的數據接口[17]，以支持IFC模型文件的解析。其中，部分軟件已通過bSI的官方驗證，如表2所示(截止至2019年4月)[18]。

表2 軟件的IFC官方驗證

作為官方驗證，bSI目前主要采用IFC2x3 CV 2.0(IFC2x3 Coordination View 2.0)作為IFC數據驗證的基準模板，對不同BIM軟件進行IFC數據輸入或輸出的驗證。從表2可見，目前有33款軟件通過IFC數據的輸入驗證，而通過IFC數據輸出驗證的軟件數量是27款。其中，只有15款軟件同時通過輸入和輸出的驗證。由于各軟件的專業(yè)性不同，IFC輸出驗證分為建筑、結構、MEP三個專業(yè)方向。例如，MagiCAD軟件通過了IFC2x3 CV 2.0-MEP的輸出驗證。

目前，bSI主要驗證各軟件對IFC2x3數據的解析情況，IFC4的驗證處于進行狀態(tài)，如bSI正在驗證Revit，ArchiCAD，Tekla Structures等軟件對IFC4的解析。建筑領域的軟件眾多，還有大量的軟件需進一步完善IFC輸入或輸出的數據接口。

3.2 IFC數據交互的不一致問題

bSI提供了IFC官方驗證方法，但各軟件采用IFC進行數據交互時仍存在數據不一致的問題。這是因為官方驗證流程主要測試標準建筑或標準構件[19]，對于實際工程項目的復雜構件，即使是通過IFC驗證的軟件，可能也不能100%準確解析該項目的IFC數據。相比于交換數據質量的驗證，IFC驗證更側重于軟件關于IFC數據的交換能力[20]。

目前，國內外學者已開展了關于不同軟件之間數據交互測試的研究[21,22]。這些研究表明，不同軟件在采用IFC進行數據共享和交換過程中，數據不一致問題頻繁發(fā)生，如對象類型不一致、對象丟失和幾何外觀錯誤等。為深入分析多專業(yè)軟件基于IFC標準的數據交互過程，筆者所在團隊曾設計多專業(yè)軟件關于IFC模型的輸入與輸出實驗[23]，測試軟件包括Revit，ArchiCAD，Tekla Structures，MagiCAD等主流軟件，測試對象包括建筑、結構、MEP等專業(yè)的典型構件。實驗總結了IFC模型輸入輸出前后，在構件類型、幾何、顏色、屬性、關系等方面的不一致問題，并揭示了形狀復雜構件的數據不一致問題最為突出。

盡管現階段各軟件在采用IFC進行數據交互時出現各種問題，但能否說明基于IFC標準的數據交互技術路線是不可行的？第4章將對該問題進行深入的討論分析。

4 發(fā)展IFC標準的挑戰(zhàn)和未來展望

IFC標準從1996年發(fā)布的IFC1.0至今，已有二十余年，雖然已得到建筑領域多種軟件的支持，但仍存在一些內部和外部的問題，在IFC標準未來發(fā)展的道路上有待進一步解決。

4.1 軟件對IFC模型數據的解析差異

根據第3.1節(jié)，bSI目前采用IFC2x3 CV 2.0作為IFC數據驗證模板。同時，IFC2x3 CV 2.0也是大部分軟件解析IFC數據的內嵌模板[24]。CV(Coordination View)是第一個官方發(fā)布的IFC子集，即MVD。該MVD可實現建設項目建筑、結構、MEP等專業(yè)之間的數據共享與交換。在默認情況下，軟件按照該MVD模式輸入或輸出IFC模型數據。現階段，bSI也發(fā)布了其他MVD，如Ifc2x3 Basic FM Handover View，IFC4 Reference View和IFC4 Design Transfer View。筆者曾嘗試采用Revit軟件，將同一模型按照不同MVD輸出，得到了具有不同表達方式的IFC模型數據(具體研究成果將在下一篇文章中整理發(fā)布)。這些MVD均是IFC的子集，定義了建設項目不同數據要求。因此，對于MVD中未定義的數據，軟件不能把該數據輸出至IFC模型文件中。這也是現階段BIM模型輸出為IFC數據時，部分數據丟失的原因之一，如構件的參數化約束關系、構件之間關聯關系等?？偨Y而言，當軟件根據不同MVD解析IFC模型數據時，可能得到不同的數據解析結果。這是不同軟件對同一IFC數據解析產生差異的原因之一。

而產生差異的第二個原因，也是最主要的原因，是軟件自身數據結構與IFC數據之間的映射關系。在筆者設計的數據交互實驗中[23]，各軟件采用默認視圖解析IFC模型數據，即IFC2x3 CV 2.0。在IFC模型輸入和輸出的過程中，存在兩種數據映射：(1)軟件將自身創(chuàng)建的專業(yè)模型輸出為IFC數據，即軟件內部數據映射為IFC數據；(2)當輸入其他軟件創(chuàng)建的IFC模型時，軟件將IFC數據映射到軟件內部數據。由于軟件對IFC數據的不完全映射，導致軟件在解析IFC模型時，出現IFC模型數據的丟失、錯漏等問題。在交互實驗中[23]，當采用IFC解析較好的軟件，數據解析的準確性較高。因此，各軟件廠商需進一步完善IFC數據接口，以提高IFC數據解析的準確性。

4.2 基于IFC標準的建筑領域構件表達方法擴展

IFC標準涉及建筑、結構、電氣、HVAC等多個領域，但主要面向民建項目。雖然IFC標準也提供了通用方法表達其他項目的專業(yè)信息，但相關的表達缺乏專業(yè)性，且可能需要更多的數據量。如橋梁項目中橋墩蓋梁和橋臺蓋梁的幾何外觀表達，采用IFC標準的面片方式表達，是一種非參數化的表達方法。不能準確、高效地表達專業(yè)信息，這是IFC標準在其他工程項目應用中受阻的主要原因。

應注意的是，IFC標準仍在不斷發(fā)展完善。IFC標準在民建項目的表達已相對完善。近幾年來，bSI已組織開展了IFC標準在市政基礎項目的擴展研究，如IFC-Road(道路)[25]、IFC-Bridge(橋梁)[26]、IFC-Tunnel(隧道)[27]、IFC-Railway(鐵路)[28]等項目，并納入了IFC5的研發(fā)計劃中。部分研究成果已發(fā)布在IFC4.1(正式發(fā)布狀態(tài))和IFC4.2(草稿狀態(tài))中。例如，在IFC4.2的架構中，已新建IfcFacility，IfcBridge等實體，為市政基礎項目的IFC擴展奠定了基礎。

可以預期，后續(xù)發(fā)布的IFC標準將涉及市政基礎項目更多信息的專業(yè)化定義，IFC標準對建筑領域各項目信息的表達將日趨完善。

4.3 IFC標準的政策支持

除建筑行業(yè)相關專家對IFC標準的支持，國內外建筑業(yè)相關機構也發(fā)布了標準規(guī)范，不斷推動IFC標準在建設項目中的BIM應用。此處以美國和我國為例。

美國BIM標準(NBIMS)從2007年發(fā)布的V1.0開始，至今已發(fā)布至V3.0(2015)。該標準規(guī)定了基于IFC的建設項目不同專業(yè)之間的數據交互要求，對BIM項目的IFC應用起到了促進作用。其中，該標準提出采用BIM能力成熟度模型(Capability Maturity Model，CMM)評估項目的BIM應用情況[29]。NBIMS給出兩類CMM：表格式CMM(Tabular CMM)和交互式CMM(Interactive CMM)。這兩類CMM均有11項評價指標(如數據豐富性、生命周期、互用性/支持IFC)，每項指標的分值共有10個等級。其中，交互式CMM根據11項評價指標的重要性劃分了權重比例，而互用性/支持IFC格式的權重比例最高?？梢奛BIMS對IFC標準的重視程度。

我國BIM應用雖然起步較晚，但近年來不同建設項目已廣泛使用BIM技術。為規(guī)范BIM應用，我國不同機構研究并發(fā)布了相關的BIM標準。表3列舉了部分BIM標準及其與IFC標準的關系。從2007年發(fā)布的《建筑對象數字化定義》開始，IFC標準逐漸得到我國建筑業(yè)的重視，且逐漸加強了與國際標準IFC的對接關系。

雖然并非是強制性要求，但IFC標準被推薦為各軟件之間交互的數據格式，促進了建設項目各方之間的數據共享與交換。隨著政府機構力度的加大，IFC標準將被廣泛接受并深入應用到實際項目中。

表3 我國部分BIM標準與IFC標準的關系一覽

4.4 IFC標準的發(fā)展預測

雖然IFC標準現階段仍存在一些問題，但作為建筑領域公認的、開放的BIM數據標準，IFC標準的發(fā)展必將逐漸成熟和穩(wěn)定。參考Gartner新興技術成熟度曲線[30]，可總結IFC標準的發(fā)展歷程，如圖5所示。Gartner新興技術成熟度曲線將新技術發(fā)展劃分為五個階段：技術萌芽期、期望膨脹期、泡沫破裂低谷期、穩(wěn)步爬升恢復期、生產成熟期。對照IFC標準的發(fā)展歷程，可總結為如下幾個階段：

技術萌芽期：IFC1.0(1996)至IFC2.0(1999)。此階段搭建完成了IFC標準的技術框架，應用領域的數據表達還相對較少。發(fā)展至IFC1.5時，才有了穩(wěn)定的開發(fā)平臺，并開始被其他軟件支持。

期望膨脹期：IFC2.0(1999)至IFC2x3 TC1(2007)。IFC標準在此階段發(fā)展迅速，每隔一定時間發(fā)布了不同的更新內容，并得到廣泛關注。例如，IFC2x建立了穩(wěn)定的基礎框架，并引入IfcXML規(guī)范；IFC2x2增加了多個專業(yè)領域；經質量改進，IFC2x3成為目前BIM軟件支持最普遍的版本。

泡沫破裂低谷期：IFC2x3 TC1(2007)至IFC4.1(2018)。IFC2x3 TC1至IFC4的發(fā)布，期間相差了近6年，IFC4與IFC4.1之間的發(fā)展時間也相差了約5年。在這11年中，由于面臨各種問題，如資金、軟件、人員等方面，IFC標準發(fā)展緩慢且艱難。

筆者認為，目前IFC標準的發(fā)展仍處于泡沫破裂低谷期階段，但IFC標準在逐步發(fā)展，且開始進入低谷階段的拐點范圍。近些年，隨著BIM技術及相關軟件的深入應用，軟件之間的數據交互需求越來越大，且越來越多的軟件開始支持IFC的解析。同時，bSI也在不斷完善IFC標準，覆蓋更多專業(yè)領域的信息表達。因此，筆者預測，隨著IFC5的發(fā)布，IFC標準將走出泡沫破裂低谷期而進入穩(wěn)步爬升恢復期，并逐步進入成熟期。

圖5 IFC標準發(fā)展路線預測

針對第4.1～4.3節(jié)所總結的問題，可通過以下三方面促進IFC的發(fā)展：

(1)提高各軟件對IFC數據的解析質量。當且僅當軟件能夠準確解析IFC模型數據，才能保證建設項目全生命周期數據的有效共享與交換。

(2)完善IFC標準對建設項目各領域的數據表達。IFC標準支持建設項目不同類型的數據表達，但目前在市政基礎領域的表達還不夠完善，仍需要更多的行業(yè)專家投入IFC標準的研究，不斷完善IFC標準。

(3)加大行業(yè)對IFC標準的支持與推廣力度。目前建筑領域相關標準或規(guī)范建議在BIM應用中使用IFC標準，但還沒有得到廣泛的執(zhí)行，仍需要不斷普及和推廣。

5 結 語

本文從BIM數據標準IFC的歷史、現狀、未來等方面，對IFC標準進行了深入分析，以期使讀者對IFC標準有更全面、更清晰的認識。發(fā)展至今，雖然IFC標準面臨各種問題，但IFC標準是建筑領域中公認的、開放的數據標準，暫時未見更有效的公共數據標準可以替代IFC，而且IFC標準對數據交互也起到了較大的促進作用。從快速發(fā)展到低谷階段，再到穩(wěn)定、成熟階段，該發(fā)展曲線符合新技術的發(fā)展歷程。因此，隨著IFC標準的不斷完善，相信IFC標準所面臨的各種問題將得到有效解決，并發(fā)展成為建設項目全生命周期BIM應用過程中高效的數據交互標準。