IFC 交換格式檔案

一、IFC 通用格式簡介

IFC 格式在 1994 年由 Autodesk 發起由 12 間美國公司成立產業交換性聯盟 (Industry Alliance for Interoperability) ， 在 1997 年 更 名 國 際 交 換 性 聯 盟 IAI(International Alliance for Interoperability)為由業界主導之非營利團體，目標 為以發佈 IFC 資料架構的資訊模型且此模型能涵蓋建築生命週期所需的資 訊，IFC 的發展架構源自 ISO-STEP 技術為基礎，主要是讓資料架構標準化的 過程，而在2005 年 IAI 正式更名為現在業界顯為人知的組織 BuildingSMART，

在全球共有13 個分會並分佈於 18 個國家，由此可見 IFC 交付格式已經逐漸成

為 AEC 產業重要的交付格式，因此本研究將著重於法規檢測項目的 IFC 對應 並提出以IFC 架構下之國內法規檢測 MVD。

本研究主要針對 IFC2x3 之版本作為探討版本，IFC 包含 800 種以上實體 物件(Entity)、358 種性質(Property Set)、121 種資料類型(Data Type)，因此我們 可以了解其資料架構的複雜性，本研究以新北市建築執照電腦輔助查核系統中 背後所需的IFC 資料來作分析。

IFC2x3 版本主要分成以下四個層級:

1.領域層(Domain Layer)

此層為AEC 產業中各個專業分工領域，其中包含結構分析(Structural Analysis Domain) 、 建 築 (Architecture Domain) 、 機 電 設 備 (Electrical Domain)、營建管理(Construction Management Domain)、物業管理(Facilities Management Domain)、暖氣空調設備(HVAC Domain)、消防管線(Plumbing Fire Protection Domain)、結構(Structural Elements Domain)各專業團隊交換 資訊定義。

2.交付層(Interoperability Layer)

此層包含了資訊模型中的共享建築物件(Building Element)、共享設備 家具物件(Facilities Element)、共享營建管理物件(Management Element) 等，也清楚定義出每個物件的性質及屬性欄位。以建築物件為例有牆、樑、

樓板、柱、門、窗戶、樓梯、坡道、帷幕牆等物件。此階層的物件編定的 完整度與命名規則的嚴謹度，因為有部分的軟體在IFCColumn 或 IFCWall 是允許建模者自由選擇，這樣的操作模式會影響各種 BIM 模型建置軟體 的IFC 轉檔匯出後資料對應的差異。

3.核心層(Core Layer)

核心階層包含廣泛且詳細的工業與非工業實體元件，以產品資料綱要 (schema)定義建築物元件組成，像是空間、基地、建築物、建築元件與資 料標註等。以建築設計而言，從建築計畫擬定的層次，對於建築的內外空 間構成與組織關係加以界定，再輔以另外兩綱要架構，定義建築設計工作

流程與管控，像是個階段應完成之任務、程序、工作流程與建築許可等。

若以法規檢測角度，所以基本名詞背後構成的要素，或法規檢測所必要被 萃取的模型資訊，都要在這階層被明確敘述，也就是模型樣版編定的資料 架構都屬於核心層的事項。因此 IFC 的專案資訊階層關係為「專案 (Project)> 敷 地 (Site)> 建 築 物 (Building)> 樓 層 (Building Storey)> 空 間 (Space)」。

4.資源層(Resource Layer)

此層為最底層的資訊，同時也是定義物件本身性質的層級，包含的範 圍有面積計算(IFCQuantityArea)、防火時效(IFCPropertySingleValue)、材 質(IFCMaterial)等物件資訊。物件性質(ObjectProperty)會顯示每一個物件 (或元素)的性質資料。從 IsDefineBy_inverse 的 IFCRelDefinesByProperties 項目，可以逐級找到相關性質資料。最底層為IFCPropertySingleVaule。因 為法規檢測所額外增加編定的資訊，因此它會在這層級Relating Objects(外 部物件資訊)分類下顯示。它的整體層級架構如下：

IFCObject(Space)→IsDefineBy_inverse→IFCRelDefinesByProperties → IFCPropertySet(Relating) →

IFCPropertySingleVaule(Haspeoperties)→Name→空間名稱(機電空間) 對照傳統交付資訊與IFC 格式交換，IFC 更全面涵蓋建築生命週期各領域 之資訊整合，包含了建築師、結構技師、機電技師、專案管理、土木技師、空 調暖氣工程師等專業人員，以IFC 為基礎進行資訊交換也降低溝通成本。

圖2-3 IFC 系統架構表

(圖片來源：BuildingSMART IFC2x3 TC1) 以IFC 格式產生的物件應包含以下特性。

1.幾何形體(Geometry)

所有實際存在且具有幾何性質描述的實體都屬於 Geometry 的範疇。

如柱體(IFCColumn)、牆體(IFCWall)、門(IFCDoor)等建築物構造體均屬之。

2.性質(Properties)

IFC 非常重視性質集(Pset_)，用於定義共用的特定性能、材料類型、

環境性質等，在 IFC 的性質會歸納到 IFCPropertySet。例如在本次研究範圍

領域層

(Domain Layer)

交付層

(Interoperability Layer)

核心層 (Core Layer)

資源層

(Resource Layer)

分析出來第一、二章的通案法規檢討項目，如門(IFCDoor)、窗(IFCWindow) 的 性 質 中 的 防 火 時 效 (Fire  Rating) 、 隔 音 等 級 (Acoustic  Rating) 、 室 外 (IsExterior)、阻煙性(SmokeStop)等性質均屬之。

3.屬性(Attributes)

用來描述物件本身的屬性，例如在 IFCRelDefineProperties 下的 Related  Objects( 內 部 資 訊 ) 下 的 Name 、 Description  、 Tag 、 OverallHeight 、 OverallWidth、Long Name 等屬性項目均屬 Attributes 的項目。這些欄位可 以用來記載各個空間本身法規的名詞。 

圖2-4 IFCSpce 與 IFCDoor 物件屬性(Attributes)資料表 4.物件關係(Relationship between objects)

物件關係(Relationship)表示物件與另一個物件連結的關係，這個關係 包含外部資訊與物件內部資訊 RelatedObjects 連結。如圖 2‐5 所示樓梯 (IFCStair)  為例，其所關聯的物件包含有結構體(柱、牆、版)、開口虛體等 物件。IFCStair 要可以跟其他空間或物件連結，有一個相當重要的連結關 係稱之為「 IFCRelContainedInSpatialStructure」，這是一個連接 IFCElement 與 IFCSpatialStructureElement 兩個元件繼承屬性的關係。讓建築物的實體 元 件 與 空 間 元 件 可 以 被 整 合 。 可 以 看 出 一 部 樓 梯 ， 透 過

IFCRelContainedInSpatialStructure 關 係 的 連 結 IFCStair 與 IFCBuilding ， IFCBuilding 與 IFCBuildingStorey 有一個上位階層的連結關係，因此透過 IFCAggregates 聚合關係協定，進行外部連結(RelatingObject 外部資訊 連結)連結 IFCBuildingStorey。在 IFCBuildingStorey 並無直接關聯，一為空 間屬性，另一為物件屬性，但 IFCWall 因 IFCLocalPlacement 而定位樓層資 訊，所以 IFCWall 與 IFCRelContainedInSpatialStructure(RelatedObjects 內部 資 訊 連 結 ) 在 內 部 物 件 組 成 關 係 (RelatedObjects) ， 再 透 過 另 一 個 連 結 IFCWall。 

進一步舉例說明，樓梯與建築物是性質不同的外部連結，建築物與樓 層同屬空間物件(IFCspace)，故有空間位置的內部連結關係，IFCAggregates 扮演連接外部與內部資訊的協調者角色。 

另 外 再 介 紹 constrainment  relationship 這 個 限 制 關 係 ， 透 過 constrainment  relationship 可以描述直接與間接存在的限制關聯，例如為 樓層資訊被 IFCLocalPlacement 定義在 4 樓層，因此 IFCWall 在 4 樓部分的 物件與樓層本來的間接關係變成具有內部關係，成為構成改樓層的元素之 一，所以物件連結變成 RelatedElement，藉由 RelatedElement 的關係可顯 示同一樓層其他樓梯或牆體樓梯間的空間位置。另一例子為樓梯與牆體兩 個物件的 constrainment  relationship 則為直接關係，因為兩者構成樓梯 間，與所在樓層無關。 

法規檢測因為要整合各樓層的資訊後進行總體數量的計算，例如當層 免計容積樓地板面積計算、總量樓地板面積計算；或者，樓梯寬度的設計 與當層樓地板面積總量作為判識基準，國外其他文獻也積極在探討以  IFCRelContainedInSpatialStructure 進行物件的關聯性編定，達到空間模型 多樣化的產製與提高物件快速查詢的效能。 

  圖2-5 樓梯約束空間與結構體的關係

(圖片來源：BuildingSMART IFC2x3 TC1)

二、IFC 架構格式定義 MVD 之應用

MVD 的產生會針對某個目標來制定，例如作為綠能分析的物件資訊 MVD，因此開窗尺寸大小、空調功率分析、外牆傳熱係數、照明耗能值等物 件性質為重要的交換資訊。

以下為構成MVD 藍圖四大要素:

1.資訊格式結構(Format)

本研究以 IFC 資料結構作為定義 MVD 的基礎，編訂法規的名詞與 IFCSpace 對應關係(詳 3.2 節)，模型樣版發布版本回直接影響 MVD 資料的 完整性，這也是新北市政府必須發布法規檢測樣版的緣由。

2.滿足資訊需求(content)

由IFC Schema 資料細項來滿足定義資訊模型物件性質(Properties)與 屬性(Attributes)並制定法規檢測之物件 MVD。

3.過程(Process)

這裡的過程不是指專案作業流程，而是指如何定義MVD 資料標準的 決策過程，由使用者對各項BIM 應用之 MVD 的制定與官方標準 MVD 的 IFC 資料格式比對並調整校對達成共識的過程，即將 IFC 性質與屬性項目 標 準 化 的 過 程 。 如 面 積 應 該 由 IFCPropertySingleValue 還 是 IFCQuantityArea 來交換。

4.工具(Tools)

對於 AEC 產業達成模型資訊的工具為相關電腦軟體，以市占率來看 有Autodesk Revit、 Bentley Architecture、Graphisoft ArchiCAD 等軟體能 幫助建築團隊以IFC 格式架構下定義之 MVD 進行資訊模型建置。

因此MVD 制訂為資訊交換(Information Delivery Manuals)重要的基礎，將 可量化之法規進行MVD 的標準制定範例，這樣的標準制定可望提供一個針對 法規邏輯化規格化的一個重要方向。

IFC 發表特定 MVD 描述(IFC  Release  Specific  MVD  Description)，參考圖 2‐6

所示，MVD 之內容在於對相關欄位有明確定義及描述，例如法規檢測面積明細 表，有關各名詞是否計入停車空間、容積樓地板面積、免計容積樓地板面積等 都要有清楚定義，重點是這個樣版必須由政府部門發布(Authors)。 

圖2-6 MVD 應用描述公版

(圖片來源: BuildingSMART alliance 2011)