運用物件導向技術於IFC建築資訊

(1)

國立交通大學

土木工程研究所

碩士論文

運用物件導向技術於

運用物件導向技術於 IFC 建築資訊

建築資訊

Object Oriented Technology Applied to IFC Building

Information

研究生

研究生：

研究生

：

：沈秉廷

沈秉廷

指導教授

指導教授：

：林昌佑

：

林昌佑

博士

中華民國

九十七

年

六

月

(2)

運用物件導向技術於

運用物件導向技術於 IFC 建築資訊

建築資訊

Object Oriented Technology Applied to IFC Building

Information

研究生研究生研究生

研究生：：：沈秉廷：沈秉廷沈秉廷沈秉廷 Student：：：Ping-Ting Shen ：指導教授

指導教授指導教授

指導教授：：：：林昌佑林昌佑林昌佑林昌佑博士博士博士博士 Advisor：：：：Dr. Chang-Yu Lin

國立交通大學

土木工程學系

碩士論文

A Thesis

Submitted to Department of Civil Engineering

College of Engineering

National Chaio Tung University

in Partial Fulfillment of the Requirements

for the Degree of

Master of Science

in

Civil Engineering

June 2008

HsinChu, Taiwan, Republic of China

中華民國九十七年六月

(3)

運用物件導向技術於 IFC 建築資訊

學生：沈秉廷指導教授：林昌佑博士國立交通大學土木工程學系(研究所)碩士班

摘要

在建築物生命週期，從規劃、建築設計、工程分析、估價發包、施工乃至營運維護，無時無刻需要進行資訊交換；然而資訊交換卻沒有一套共同標準，使得資訊在交換過程中時常發生錯漏，或是相同的資訊卻要重新建檔，再用性不佳，管理上也相當不易。由 IAI(International Alliance for Interoperability)國際組織提出的 IFC(Industry Foundation Classes)是一種公開的資訊交換標準，目的在使整個建築物生命週期的所有資訊能夠整合在一個建築資訊模型中(BIM, Building Information Model)，讓生命週期中所有軟體能夠共享、交換資訊。

本研究由物件導向的觀點探討 IFC 規格 (Specification) 設計與實作 (Implementation)方式，介紹兩種免費的 IFC 實體檔案存取應用程式介面(API, Application Programming Interface)，並探討其 IFC 資訊存取方式。

本研究並運用物件導向技術，自行撰寫程式將 IFC Entity 規格轉換為.Net Framework 類別(Class)，再以類別庫(Class Library)封裝。此類別庫提供較直觀的 IFC 應用程式開發方式，並能夠運用物件導向於系統開發。本研究最後使用所建置之類別庫開發以 Plug-In 為架構的 IFC BIM 系統，並開發一些 Plug-In 元件進一步示範如何應用類別庫，包含: 3D 建築模型瀏覽、建築物框架建模、樑柱斷面資訊瀏覽 Plug-In 元件。

(4)

Object Oriented Technology Applied to IFC Building

Information

Student：Ping-Ting Shen Advisor：Dr. Chang-Yu Lin

Institute of Civil Engineering

National Chiao Tung University

ABSTRACT

Information exchange is an important issue during the life circle of a building. However, the lack of exchange standard usually results information leakage and low efficiency. IFC (Industry Foundation Classes) which introduced by IAI (International Alliance for Interoperability) is an open standard for information exchange. IFC aims to describe all the information relating to a building’s life circle and integrates them into a Building Information Model (BIM). Consequently, information can be exchanged and shared via BIM.

This research discusses the specification and implementation of IFC in an Object Oriented approach. Two charge-free APIs (Application Programming Interface) are discussed.

Additionally, this research introduces an IFC based .Net Framework class library which provides an easier and safer way to access IFC file. Also, this class library can be easily applied to Object Oriented programming. Finally, this research presents a Plug-In based IFC system, and demonstrates how to use this class library to develop Plug-In component, includes 3D building model viewer, building infrastructure builder, and beam/column profile viewer.

(5)

誌謝

研究所這兩年是我最快樂的求學生活，很高興能夠到交大唸書，這段期間在專業知識與待人處事上皆有所成長。首先要感謝我的指導教授林昌佑博士，對於學生在修課與論文撰寫，教授提供了許多協助與指導並給予學生相當大的研究自由，感激之情溢於言表。在研究的過程中，感謝研究室成員：學長奕銘、益世、啟勇、弘毅、志偉及學姊雅晶還有學弟妹們，提供我許多建議與協助。另外感謝，同學承禹、昱德、昊志、怡廷，以及志銘、君暉等 IT 組的學弟妹，因為你們讓我的研究生活更充實。在論文口試期間，要感謝交通大學洪士林教授、趙文成教授提供了很多寶貴的意見及建議，讓論文疏漏之處得以改進。在此深表感謝。最後要感謝我的家人，尤其是我的父母，感謝你們的養育與栽培，在求學過程中給予我支持與鼓勵，讓我可以順利獲得碩士學位，希望你們身體健康，平安快樂。

(6)

摘要摘要摘要摘要 ... i ABSTRACT ... ii 誌謝誌謝誌謝誌謝 ...iii 目錄目錄目錄目錄 ... iv 表目錄表目錄表目錄表目錄 ... vi 圖目錄圖目錄圖目錄圖目錄 ... vii 第一章第一章第一章第一章緒論緒論緒論緒論 ... 1 1.1 研究背景研究背景研究背景研究背景... 1 1.2 研究動機與目的研究動機與目的研究動機與目的研究動機與目的... 1 1.3 研究內容研究內容研究內容研究內容... 2 1.4 研究流程研究流程研究流程研究流程... 2 1.5 論文架構論文架構論文架構論文架構... 3 第二章第二章第二章第二章研究相關知識研究相關知識研究相關知識研究相關知識 ... 4 2.1 建築資訊模型建築資訊模型建築資訊模型建築資訊模型////建築資訊塑模建築資訊塑模建築資訊塑模建築資訊塑模... 4 2.2 建築資訊交換標準建築資訊交換標準建築資訊交換標準建築資訊交換標準... 5 2.2.1 STEP... 5 2.2.2 IFC... 6 2.2.3 CIS/2... 8 2.3 物件導向物件導向物件導向物件導向... 8 2.3.1 物件導向基本概念物件導向基本概念物件導向基本概念物件導向基本概念 ... 8 2.3.2 物件導向於建築資訊交換標準的應用物件導向於建築資訊交換標準的應用物件導向於建築資訊交換標準的應用物件導向於建築資訊交換標準的應用 ... 10

2.4 .Net Framework.Net Framework.Net Framework.Net Framework... 10

2.5 IFC 相關應用研究相關應用研究相關應用研究相關應用研究... 11 第三章第三章第三章第三章 IFC 規格與實作規格與實作規格與實作規格與實作 ... 13 3.1 IFC 資訊描述方式資訊描述方式資訊描述方式資訊描述方式... 13 3.2 物件導向於物件導向於物件導向於物件導向於 IFC 規格運用規格運用規格運用規格運用... 15 3.2.1 繼承繼承繼承繼承... 16 3.2.2 抽象資料類型與多型抽象資料類型與多型抽象資料類型與多型抽象資料類型與多型 ... 17 3.3 IFC 規格基礎架構規格基礎架構規格基礎架構規格基礎架構... 19 3.4 IFC 建築資訊模型與模型視圖建築資訊模型與模型視圖建築資訊模型與模型視圖建築資訊模型與模型視圖... 21 3.4.1 基礎基礎基礎基礎 IFC 建築資訊模型建築資訊模型建築資訊模型建築資訊模型... 21 3.4.2 模型視圖模型視圖模型視圖模型視圖... 22 3.5 IFC 實體檔案格式實體檔案格式實體檔案格式實體檔案格式... 23 3.6 IFC 資訊存取應用程式介面資訊存取應用程式介面資訊存取應用程式介面資訊存取應用程式介面... 24 3.6.1 IFCsvr ... 24

(7)

第四章第四章第四章第四章 IFC 類別庫類別庫類別庫類別庫 ... 28 4.1 類別庫架構類別庫架構類別庫架構類別庫架構... 28 4.2 IFC 資料類型映對資料類型映對資料類型映對資料類型映對... 29 4.2.1 Defined Type ... 29 4.2.2 Enumeration ... 29 4.2.3 Select Type ... 30 4.2.4 Entity ... 30 第五章第五章第五章第五章 IFC 類別庫使用範例與應用類別庫使用範例與應用類別庫使用範例與應用類別庫使用範例與應用 ... 35 5.1 IFC 類別庫使用範例及與類別庫使用範例及與類別庫使用範例及與類別庫使用範例及與 IFCsvr 之比較之比較之比較之比較 ... 35 5.1.1 IFC 資訊建立資訊建立資訊建立資訊建立... 35 5.1.2 IFC 資訊擷取資訊擷取資訊擷取資訊擷取... 39 5.2 IFC 類別庫於物件導向程式設計之運用類別庫於物件導向程式設計之運用類別庫於物件導向程式設計之運用類別庫於物件導向程式設計之運用... 40 5.2.1 繼承繼承繼承繼承... 40 5.2.2 多型多型多型多型... 42 5.3 IFC 類別庫應用類別庫應用類別庫應用類別庫應用... 43 5.3.1 Plug-In 架構架構架構架構 IFC 資訊系統資訊系統資訊系統資訊系統... 43 5.3.2 3D 建築模型瀏覽建築模型瀏覽建築模型瀏覽 Plug-In 元件建築模型瀏覽元件元件元件... 44 5.3.3 建築物框架建模建築物框架建模建築物框架建模建築物框架建模 Plug-In 元件元件元件元件... 45 5.3.4 樑柱斷面資訊瀏覽樑柱斷面資訊瀏覽樑柱斷面資訊瀏覽樑柱斷面資訊瀏覽 Plug-In 元件元件元件... 48元件 5.3.5 小結小結小結小結... 50 第六章第六章第六章第六章結論與建議結論與建議結論與建議結論與建議 ... 51 6.1 結論結論結論結論... 51 6.2 建議建議建議建議... 52 參考文獻參考文獻參考文獻參考文獻 ... 53 附件一附件一附件一附件一 ... 84 附件二附件二附件二附件二 ... 94

(8)

表目錄

表 2-1 BIM 系統整理 ... 55 表 2-2 STEP/IFC/CIS2 比較... 55 表 4-1 IFC 基礎資料型態映對到 VB.net 資料型態 ... 56 表 5-1 IFCsvr 與 IFC 類別庫資訊存取比較 ... 56

(9)

圖

圖目錄

圖 3-1 IfcExtrudedAreaSolid 形狀[5]... 60 圖 3-2 IfcProfileDef 繼承關係 ... 60 圖 3-3 IFC 基礎 Entity 繼承關係... 61 圖 3-4 IFC 建築資訊模型基本 Entity 關係... 62 圖 3-5 IfcSpatialStructureElement 分解圖[5]... 63 圖 3-6 IFCsvr 架構... 63 圖 4-1 本研究建立之 IFC 類別庫架構... 64 圖 4-2 Enumeration 轉換範例 ... 65 圖 4-3 Select Type 轉換範例 ... 65 圖 4-4 IfcProject 類別映對 ... 66 圖 4-5 資料擷取呼叫順序... 66 圖 4-6 部分已轉換類別... 67 圖 5-1 範例輸出檔... 68 圖 5-2 類別庫與 IFCsvr 屬性存取比較... 68 圖 5-3 自定義 IfcBeam 模型視圖 ... 69 圖 5-4 範例輸出檔... 69 圖 5-5 輸出範例... 70 圖 5-6 Entity 物件屬性存取 ... 70 圖 5-7 型別轉換錯誤... 71 圖 5-8 Plug-In 系統架構... 71 圖 5-9 主應用程式使用者介面... 72 圖 5-10 主應用程式樹狀結構視窗... 72 圖 5-11 3D 建築模型瀏覽 Plug-In 元件-1... 73 圖 5-12 3D 建築模型瀏覽 Plug-In 元件-2 ... 73 圖 5-13 IFC 建築物模型視圖... 74 圖 5-14 建築物框架建模 Plug-In 元件架構... 75 圖 5-15 新建 IFC 檔案... 75 圖 5-16 啟動 Plug-In... 76 圖 5-17 初始畫布視窗... 76 圖 5-18 新增樓層-1 ... 77 圖 5-19 新增樓層-2 ... 77

(10)

圖 5-20 選擇樓層... 78 圖 5-21 斷面選擇視窗... 78 圖 5-22 新增柱元件... 79 圖 5-23 新增樑元件... 79 圖 5-24 新增樑柱元件... 80 圖 5-25 樹狀結構更新... 80 圖 5-26 啟動 3D 模型瀏覽 Plug-In 觀看模型... 81 圖 5-27 將模型載入 ArchiCad ... 81 圖 5-28 樑柱斷面資訊瀏覽 Plug-In 元件架構... 82 圖 5-29 樑柱斷面資訊瀏覽 Plug-In 元件-1 ... 82 圖 5-30 樑柱斷面資訊瀏覽 Plug-In 元件-2 ... 83

(11)

第一章

第一章緒論

緒論

1.1 研究

研究

研究背景

背景

AEC/FM(Architecture,Engineering,Construction and Facilities Management) 領域中，一個建築物從規劃、建築設計、工程分析、估價發包、施工乃至營運維護，每一階段都牽涉到許多專業分工。各專業之間的互動相當的複雜，大量的資訊必須在不同專業領域間交換傳遞，故資訊如何完整且有效的在各階段傳遞、分享是相當重要的議題。

隨著電腦輔助設計(Computer-Aided Design, CAD)方法的發展及電腦輔助繪製設計系統(Computer-Aided Drafting and Design System, CADD)的普及，傳統的紙本資料(建築圖、工程圖、計算書等)逐漸被電子檔案取代。然而各家軟體公司採用的資訊描述格式不盡相同，導致在資訊交換傳遞過程中經常發生錯誤漏失，或是相同的資訊卻要重新建檔檢核，無法有效的分享資訊，除了浪費時間與人力，管理上也相當不易。

於是有後續研究提出了建築資訊模型(Building Information Model,BIM) 的概念，希望將整個建築物生命週期所涵蓋的資訊保存在同一個資訊模型，讓建築物生命週期各階段的軟體能夠直接從這個資訊模型分享、交換資訊。為了能夠讓資訊完整有效的在各階段所使用的軟體間交換，軟體間需要有一個建築資訊交換標準，此標準必須能夠描述建築物生命週期各階段所涵蓋的資訊，並且受到各軟體的支援。

在資訊交換標準的發展方面，國際標準組織(International Organization for Standardization,ISO)提出了 STEP(Standard for the Exchange of Product model data) ，，，工業產品資訊交換標準；NIST(National Institute of Standards and ， Technology)提出了 CIS/2(CIMsteel Integration Standards Release 2)，鋼結構資訊交換標準； IAI(International Alliance for Interoperability) 則提出了 IFC(Industry Foundation Classes)，為 AEC/FM 領域公開資訊交換標準。

1.2 研究動機

研究動機

研究動機與

與

與目的

目的

資訊的標準化是一股難以忽視的趨勢，IFC 在國外已經有相當多的研究，並有許多軟體公司已經開始遵循此標準。然而國內對於 IFC 的研究應用目前尚不多，為了促進國內對於建築資訊模型及資訊交換標準的研究發展與應用，本研究以 IFC 這個針對 AEC/FM 領域制定的資訊交換標準為對象，進行探討其規格及實作方法。

(12)

為了能夠快速的建立、擷取 IFC 資訊，本研究運用物件導向技術，自行撰寫程式將 IFC Entity 規格轉換為.Net Framework 類別(Class)，再以類別庫 (Class Library)封裝，讓程式開發人員能夠更快速擷取、建立 IFC Entity 資訊，並運用物件導向於系統開發。

1.3 研究內容

研究內容

本研究由物件導向的觀點探討 IFC 規格 (Specification) 設計與實作 (Implementation)方式，介紹兩種免費的 IFC 實體檔案存取應用程式介面 (Application Programming Interface, API)，並探討其 IFC 資訊存取方式。

本研究並運用物件導向技術，自行撰寫程式將 IFC Entity 規格轉換為.Net Framework 類別，再以類別庫封裝。此類別庫提供較直觀的 IFC 應用程式開發方式，並能夠運用物件導向於系統開發。本研究最後使用所建置之類別庫開發以 Plug-In 為架構的 IFC BIM 系統，並開發一些 Plug-In 元件進一步示範如何應用類別庫，包含: 3D 建築模型瀏覽、建築物框架建模、樑柱斷面資訊瀏覽 Plug-In 元件。

1.4 研究

研究

研究流程

流程

1. 文獻回顧及研究相關知識加強: 蒐集閱讀關於 IFC 的資訊及文獻，並加強物件導向的基本概念。熟悉.Net Framework 及相關工具。 2. 研究 IFC 規格:

由 IAI International 官方網站下載最新版的 IFC 規格，了解其架構以及如何實作一個完整且有效的 IFC 檔案。使用幾種支援 IFC 輸入/出軟體，觀察其對 IFC 的支援情形。嘗試使用幾種 IFC 資訊存取應用程式介面(API, Application Programming Interface)，並了解其運作方式。

3. IFC 類別庫設計/實作:

先根據 IFC 規格設計 IFC 類別庫。再撰寫類別轉換器將 IFC 規格中的 Entity 轉換為類別，最後以類別庫封裝並編譯成 DLL(Dynamic-Link Library)。 4. 類別庫測試/修正: 使用類別庫實際進行資訊擷取與建立，檢討是否有需要改進及修正的地方。 5. 類別庫應用: 實際應用類別庫進行 BIM 系統的開發，本研究先建置一個 Plug-In 系統，再利用類別庫開發 Plug-In。

(13)

1.5 論文架構

論文架構

本論文總共分為六章。第一章為緒論，包含研究背景、研究動機與目的、研究內容、研究流程、論文架構，接著第二章為研究相關知識，包含建築資訊模型與建築資訊塑模、介紹相關建築資訊交換標準、物件導向基本概念、.Net Framework 介紹及相關應用研究探討。第三章為 IFC 規格與實作，包含 IFC 資訊描述方式、物件導向於 IFC 規格運用、IFC 規格基礎架構、IFC 建築資訊模型與模型視圖、IFC 實體檔案格式，並介紹兩種 IFC 資訊存取應用程式介面。本論文第四章則在描述本研究提出之 IFC 類別庫的設計及建立細節，包含類別庫的架構及如何將 IFC 規格中的資料類型映對到程式語言以便進行資訊擷取建立，接著第五章為 IFC 類別庫的使用範例及應用，使用範例包含建立、擷取 IFC 檔案資訊及如何應用 IFC 類別庫於物件導向程式設計，應用部分為示範如何使用類別庫開發 BIM 系統，最後第六章為結論與建議。

(14)

第二章

第二章研究

研究

研究相關

研究

知識

本章闡述關於本研究的相關知識，包括:建築資訊模型與建築資訊塑模、簡介 STEP、CIS/2、IFC 三種資訊交換標準、介紹物件導向的基本概念、.Net Framework 簡介、相關研究文獻回顧。

2.1 建築資訊模型

建築資訊模型

建築資訊模型/

//

/建築資訊塑模

建築資訊塑模

建築資訊模型，是建築物在整個生命週期中所有產生與關聯的資訊集合體；建築資訊塑模(Building Information Modeling)則是指建立及管理建築資訊模型的過程。在塑模的過程中應謹慎考量模型資訊交換性(interoperable)及再利用性(reusable)。

一個 BIM 系統泛指能夠在建築物生命週期中建立、整合(integrate)及重複利用建築資訊與專業知識(domain knowledge)的系統[1]。BIM 系統結合 IT(Information Technology)技術、電腦輔助設計方法，以及 AEC/FM 領域的專業知識，以設計的角度建立、整合建築資訊模型。與以往認知的電腦輔助繪製設計系統最主要不同在於電腦輔助繪製設計系統主要以繪製幾何圖形資訊為主，而且從這些輸出的幾何圖形中無法直接取得有意義的資訊(例如門窗的型號、樑柱的長度)，必須經由人員判讀才能轉為有用的資訊，而 BIM 系統能夠由資訊模型中直接取得所需資訊。一個 BIM 系統具有以下特性: 1. BIM 系統具有輸入/輸出建築資訊模型的能力。BIM 系統能夠輸入建築資訊模型進行資訊處理動作，也能夠將處理後的建築資訊模型輸出。 2. BIM 系統間能夠有效的分享資訊。一個建築物在不同階段的專業領域間必定有許多相關聯的資訊，這些資訊在 BIM 系統間必須能夠同步且有效的分享。例如當建築師使用建築 BIM 系統修改了某根樑的位置，結構技師的 BIM 系統必須能夠直接由建築 BIM 系統輸出的建築資訊模型顯示被改變的資訊。 3. BIM 系統將資訊的處理重心放在物件(Object)本身，每個物件都具有個別身份(Identity)與意義，並且含有關於此物件的相關資訊，這些資訊能夠以參數(Parametric)形式描述這個物件，例如一個樑的物件具有其位置、幾何、數量資訊。 BIM 系統涵蓋的範圍相當廣，包含建築規劃設計、結構分析模擬、建築機電、施工排程，營運管理…等。目前市面上已經有不少 BIM 系統，依照其所屬領域及開發公司整理如表 2-1。

(15)

2.2 建築資訊交換標準

建築資訊交換標準

為了讓不同 BIM 系統能夠完整有效的進行資訊交換，必須有一個描述建築資訊模型的資訊交換標準，若此系統為 BIM 的血肉，這個資訊交換標準即為 BIM 的靈魂，此標準必須能夠描述建築物生命週期各階段所涵蓋的資訊，並且受到各 BIM 系統的支援。目前較被 BIM 系統開發公司接受的標準有： STEP(Standard for the Exchange of Product model data) 、 IFC(Industry Foundation Classes)、CIS/2(CIMsteel Integration Standards Release 2)，分別介 紹於以下章節，並將三種資訊標準的比較整理於表 2-2。

2.2.1 STEP

STEP(Standard for the Exchange of Product model data)為國際標準組織 (ISO, International Organization for Standardization)提出的產品資訊交換標準，代號為 ISO10303，目的在於提供一個機制以描述整個產品生命週期的相關資訊，方便資訊交換，STEP 能夠描述的產品範圍很廣，幾乎涵蓋整個製造工業，包含:營建、機電、造船、航空...等。現由 ISO:TC184/SC4(ISO Technical Committee184-Sub-committee 4)[2]負責維護，並定期召開會議修訂標準。STEP 由許多部分標準(part standard)組成，並可分為 9 個區塊(圖 2-1)。敘述如下: 1. 描述方法(Description methods Parts 1-19)

定義 STEP 的規格，其中 part11 為 EXPRESS 資訊塑模語言(data modeling language)。EXPRESS 能夠運用物件導向的概念於資訊描述，其資訊描述語法很像 PASCAL 程式語言，但基本上 EXPRESS 所描述的資訊是獨立於程式語言的，如同描述程式流程的虛擬碼。此描述語言也被運用於描述 IFC 及 CIS/2 的規格。

2. 實作方法(Implementation methods Parts 20-29)

說明如何實現 STEP 標準，其中 part21 定義 STEP 實體檔案格式(STEP Physical File)，將資訊模型以實體檔案表示，IFC 及 CIS/2 亦使用此方法表示資訊模型。

3. 一致性測試方法及架構(Conformance testing methodology and framework Parts 30 -39)

資料在設計完成後必須通過驗證才能符合 STEP 標準，這部份定義了驗證資料的方法及相關測試。

(16)

4. 整合性一般資源(Integrated generic resources Parts 40-49)

定義了各領域的一般性資源，如形狀、尺寸、單位的描述方式。 5. 整合性應用資源(Integrated application resources Parts 100 - 199)

根據一般性資源定義特定領域的資源，如營建領域定義了樑、柱、牆等元件。

6. 應用協定(Application protocols Parts 200 - 299) 規定特定領域實現標準的需求資料。

7. 抽象測試套件(Abstract test suites Parts 300 - 399) 用來測試是否符合應用協定。

8. 應用解釋結構(Application interpreted constructs Parts 500 - 599) 用於開發新的資料模型。

9. 應用模組(Application Modules Parts 1000 - ) 為小型的資訊模型，用於開發新的應用協定。

2.2.2 IFC

IFC(Industry Foundation Classes) 由 IAI(International Alliance for Interoperability)國際組織[3]提出且維護，針對 AEC/FM 領域設計的公開資訊交換標準。目的在於讓建築物生命週期所有軟體能夠藉由 IFC 描述建築資訊，進而提高資訊的交換性與再用性。IAI 推動的 BuildingSmart[4]計畫即是以 IFC 為基礎實現 BIM 的理念。IFC 規格的發展進度見圖 2-2，IFC 從 1.5 版開始釋出，目前最新版為 2x3 Final[5]，亦為本研究所使用的 IFC 版本。

IFC 以物件導向(Object Oriented)為基本概念，參考引用了 STEP 部分標準，為了實作考量也參考了 C/C++程式語言的一些特性。以架構而言可以分為四個層次[6](圖 2-3)，由下而上分別為:資源層(Resource Layer)、核心層(Core Layer)、資訊交換層(Interoperability Layer)、專業領域層(Domain Layer)，每層分別定義了不同的種類的資料類型(Data Type)與實體(Entity)，分別敘述如下: 資源層資源層資源層資源層:::: 位於 IFC 架構的最底層，此層定義較一般性的實體，有點像是 STEP 的整合性一般資源，通常它們都是被較高層次的實體參考，例如:幾何形狀

(17)

被一個產品參考，也就是一個產品具有幾何形狀這個資訊，當產品存在時它的幾何形狀才能被定義，但也有例外：工具資源(Utility)、量測資源 (Measure)部份可以單獨存在。核心層核心層核心層核心層:::: 此層定義 IFC 基礎的實體，此層的實體定義了許多共同的介面，它們可被資訊交換層或專業領域層的實體參考或繼承。此層又可細分為兩層:內核(Kernel)層與產品延伸(Product Extension)層。內核層定義最基礎的實體，這些實體不被限定在 AEC/FM 領域，並只能參考資源層的實體，例如定義“產品”具有 “位置”與“形狀描述”這兩個屬性。產品延伸層定義較高階的實體，他們皆繼承自內核層的實體，而且都是屬於 AEC/FM 領域，例如:建築物實體。資訊交換層資訊交換層資訊交換層資訊交換層:::: 此層定義能夠在 AEC/FM 領域內做資訊交換的共同實體，例如:樑、柱、門、窗、空間…等資訊；並且，各個專業領域可將其資訊附加於此層的實體上，例如:樑柱上可能有材料資訊、施工/完工日期、結構分析結果… 等資料。專業領域層專業領域層專業領域層專業領域層:::: 此層為定義 AEC/FM 內各專業領域的實體，包含:建築、結構分析、營建管理、設施管理、機電設備、水電空調、配管工程…等專業領域的實體，例如：結構分析的分析模型、結構分析的束制條件、營建管理的人力資源。目前此層定義尚未完備，由於牽涉到許多專業領域，故標準訂定有一定的困難。 IFC 2x 有一個基本的層與層間相互參考(reference)的原則，“重力原則”(Gravity Principle)[7](見圖 2-4)，規定各層級的實體只能與相同層級的實體或低於此層級的實體相互參考，例如資源層的實體無法參考核心層的實體，所有 IFC 的規格設計都緊緊遵循著此原則。目前已有多家軟體廠商認同 IFC 建築資訊交換標準，並努力讓自家軟體支援 IFC 建築資訊模型的輸入/輸出，也有不少軟體已通過 IAI 的 IFC 相容性驗證，在 IAI ISG(Implementer Support Group)網站[8]上有建立相容軟體資料庫，雖然各家軟體廠商支援程度不一，但隨著 IFC 規格的更趨成熟，相信支援度會愈來愈高。本研究在第三章會就 IFC 的規格定義及實作方式做進一步的探討。

(18)

2.2.3 CIS/2

CIS/2(CIMsteel Integration Standards Release 2)，為 NIST(National Institute of Standards and Technology)[9]提出，目的在提供鋼結構建築物一套資訊交換的標準。CIS/2 包含了整個鋼結構生命週期的資訊，包括分析、設計、細部設計、製造。CIS/2 與 IFC 同樣使用 EXPRESS 語言描述規格。CIS/2 有三個主要的模型[10]，分別敘述如下: 分析模型分析模型分析模型分析模型(analysis model) 一個分析模型包含許多節點(node)與元素(element)支援幾種靜態(static) 與動態(dynamic)分析方法。設計模型設計模型設計模型設計模型(design model) 一個設計模型包含許多設計組合(design assembly)，每個設計組合又可分解為更多的部分設計(design part)及連結系統設計(design joint system)。製造模型製造模型製造模型製造模型(manufacturing model)))) 一個製造模型包含許多細部製造組合(manufacturing assembly)，用於細部設計、規劃、製造。

CIS/2 已被許多軟體支援，NIST 也致力於 CIS/2 與其他資料格式的交換，並開發了一個“CIS/2 to VRML and IFC Translator”軟體，允許將 CIS/2 的檔案轉為 IFC 或是 VRML (Virtual Reality Modeling Language)。

2.3 物件導向

物件導向

物件導向為一種程式設計的方法論，與結構化程式設計 (structured programming)最大的不同在於將程式分解的方法，但其核心想法都為 “各個擊破 ”(divide-and-conquer)[11] 。結構化程式設計將程式視為一個程序 (process)，再依演算法或功能性分解為許多模組(module)，每個模組都可視為程序的步驟(step)之一。物件導向程式設計將程式視為一個物件的集合體，藉由物件之間的互動建構程式，將程式分解為物件後，再對物件做功能上的分解。使用物件導向分解程式，最主要的優點讓整個程式更有彈性，並讓程式更容易再利用(reuse)。

2.3.1 物件導向基本概念

物件導向基本概念

物件導向具有幾個基本概念，分別敘述如下：

(19)

類別類別類別類別(Class) 類別為物件的規格，定義物件的屬性(attribute)、方法(method)。類別可視為物件的模子，例如:“生物”類別，定義了名稱、種類…等屬性及生長、繁殖、死亡 … 等方法，所有屬於生物的物件都具有這些成員 (member)，這些成員也可視為這些物件的介面(interface)。物件物件物件物件(Object) 物件為類別程式執行時期(runtime)的實例(instance)，能夠藉由呼叫物件的方法進行運算及擁有自己的狀態(state)，例如: 你跟我都是屬於 “人” 這個類別，你我都具有“姓名”這個屬性，但很有可能我們的姓名是不一樣的，也就是我們各自擁有不同的狀態。繼承繼承繼承繼承(Inheritance) 子類別(subclass)可藉由繼承父類別(super class)擁有父類別的所有成員，並可額外擁有自己的成員或是覆寫(override)父類別的方法，子類別是父類別的一種，所以父類別也能夠視為所有子類別的介面，例如: “貓”類別與“狗”類別都是繼承自 “生物”類別，他們都具有生物的成員，也各自擁有自己其他的成員，貓可能有 “抓老鼠”這個方法，狗有“看門”這個方法。封裝封裝封裝封裝(Encapsulation) 封裝或是資訊隱藏(Information Hiding)目的在將實作的細節與私有成員隱藏起來，對於該物件的操作只能根據其公開成員，就像我們沒辦法由晶片的成品直接了解其電路設計一樣。資料抽象化資料抽象化資料抽象化資料抽象化(Data Abstraction) 資料抽象化目的在將物件的介面與實作分開來，例如:對於“汽車”物件，我們只要知道它能駕駛就夠了，至於怎麼製造生產對我們不是太重要。抽象資料類型(ADT, Abstract data type)為一種特別的資料型態，它用以表示類別的介面，一個類別能夠實現許多不同介面，例如: “狗”類別實現了 “寵物”跟“朋友”的介面，你可以把牠當作寵物也可以當做朋友。多型多型多型多型(Polymorphism) 多型是指不同的物件能夠藉由相同的介面加以操作，結果會因為實作的不同而有異。例如:“狗”類別與“貓”類別都有實作“寵物”這個介面，你可以將狗跟貓都當作寵物看待，但身為寵物，狗跟貓表現出的行為是很不一樣的。當我們說一個程式語言支援物件導向，那它必須具有下列特性:

(20)

1. 它必需支援物件。 2. 物件必須屬於某一類別。 3. 必需支援繼承。一個程式語言支援前兩項特性，但不支援繼承時只能稱為物件基礎語言 (object-based language)。目前常見支援物件導向程式語言有:C++、Java、C#、 VB.net。雖然 C 語言不支援物件導向，但是由於語言本身彈性很大，能夠直接操控記憶體，要實現物件導向也是可能的，如 Linux 核心主要以 C 語言撰寫卻能活用許多物件導向的概念。

2.3.2 物件導向於

物件導向於

物件導向於建築

建築

建築資訊

資訊

資訊交換

交換

交換標準的應用

標準的應用

物件導向以物件為基礎的思考方式，非常適合用於表達真實世界的事物，STEP、IFC、CIS/2 三種資訊交換標準皆參考了物件導向的概念，用以描述資訊。AEC/FM 的產品是由建築元件組成，例如一棟建築物含有樑、柱、牆、版、門窗、樓梯...等建築元件，每一個元件皆可視為物件，其各自包含自己的屬性，例如一根樑有斷面、位置、長度、材料…等屬性。利用物件導向繼承的概念能夠很容易的擴展物件的資訊，例如制定“建築元件”這個物件可能定義了較一般性的資料像是使用材料、是否為受力元件，“樑”物件跟 “樓梯”物件，繼承自“建築元件”他們除了擁有自己的屬性外同時也擁有“建築元件”的屬性。許多 BIM 系統在處理建築資訊上也運用了物件導向的概念，以建築設計為例，傳統的 CADD 系統(如 AutoCAD, MicroStation, QuickCad)，對於真實世界的建築元件，只是由點、線、弧形等幾何訊組成；而建築設計 BIM 系統 (如 Revit、ArchiCad、Bentley Architecture)對於建築元件則是對應到一個物件，並藉由參數化的方式進行設計。

2.4 .Net Framework

.Net Framework

.Net Framework 是微軟(Microsoft)提出於 Windows 平台的軟體開發、建置、執行方案。它包含了兩個主要的部份[12]：

1. 基礎類別庫(Base class library)，包含使用者介面、資料存取、資料庫、演算法、網路通訊…等許多作業系統的功能，此類別庫運用許多物件導向概念建置，讓程式開發者快速的使用這些類別，降低程式開發者的負擔。

2. CLI(Common Language Infrastructure)架構(圖 2-5)，CLI 又分為兩個部份 CIL(Common Intermediate Language)以及 CLR(Common Language Runtime)。

(21)

CIL 為一種中繼語言，如同 Java 的位元組碼(Byte Code)，使用微軟提供的不同程式語言的編譯器能夠將不同程式語言的程式碼編譯成 CIL，並且這些程式語言都能夠使用基礎類別庫進行開發程式，目前支援的程式語言有:Visual C++、Visual Basic.Net、C#、J#，雖然使用的語言不同但最終都會編譯成 CIL。 CLR 扮演一個虛擬機器的角色，如同 Java 的 JVM(Java Virtual Machine)，它負責在執行時將 CIL 轉換為該平台的原生碼(Native Code)，屬於 JIT 編譯器 (Just In Time Compiler)。

.Net Framework 具有幾個特點[12]: 1. 安全：由於 CIL 含有整個程式的所有資訊，故能夠在程式載入時做型別和程式碼驗證。 2. 跨平台：由於所有的程式碼最終都編譯成 CIL，故只要在不同平台實現 CLR 即可達到跨平台的效果。 3. 互動性高：能夠與微軟的過去的一些技術結合，像是 COM(Component Object Model)技術、OLE(Object Linking and Embedding)技術。

本研究主要使用.Net Framework 1.5 版及 Visual Basic .Net 程式語言，雖然目前最新版為 3.5，但 1.5 的功能對於本研究已經足夠。

2.5 IFC 相關

應用

應用研究

研究

對於 IFC 建築資訊交換標準已經有不少研究與應用，在 IFC 應用與研究的過程中為了從 IFC 實體檔案建立或擷取建築資訊模型的資訊，必須有一個存取實體檔案的方法，當然我們也可以開啟 IFC 檔案直接從文字檔案抓取資訊，但若是能夠藉由一個應用程式介面存取資訊，我們可以在不同的程式中使用相同的方法存取資訊，讓程式更容易重複使用。近年來國外對於 IFC 應用之研究有：

Po-Han Chen 等人(2004)以 IFC 為基礎並使用 JavaEE 技術及 XML 技術建立一個資訊交換伺服器，讓建築師與結構技師能夠藉由 IFC 建築資訊模型與網路技術進行協同設計。M.Hassanien Serror 等人(2007) 從結構分析的角度探討如何運用 IFC 建築資訊模型實現建築物結構分析模型，並實際運用於結構分析，此研究部分被 IAI 採用以進行 IFC 的設計。

Ali Murat Tanyer 等人(2004) 建立一個以 IFC 為基礎的資料庫，並開發結合 4D 建築工程規劃及估價的系統，能夠從這個資料庫取得建築資訊模型。Changfeng Fu 等人(2005) 使用 IFCsvr API 開發一個能夠瀏覽 IFC 建築資訊模型內容的系統，由三維圖形出發到多維的資訊，如時間、成本等專案相關資訊。

(22)

國內對於 IFC 近年來有愈來愈多的相關研究，最近幾年對於 IFC 的相關研究有：蘇建豪(2000)嘗試將 STEP、IFC 等資訊標準運用於工程資訊管理，藉由建立標準資訊模型進行資料交換並將所有電子資訊存入物件導向資料庫中，形成一虛擬中心資料庫，達成資訊共享之目的。潘稟嘉(2000)將 IFC 建立的營建圖檔資訊以網路方式共享，讓 IFC 圖形資訊能夠透過網路進行解讀、存取及展示，並應用互動式網頁技術，將 IFC 檔案動態轉換為 VRML，並建立 IFC 共享資料庫，讓 IFC 圖檔資訊能夠過資料庫進行存 取，在 IFC 資訊的存取上為使用自行撰寫的 VB 程式處理。 蔡志偉(2007)針對結構分析所需資料進行擷取 IFC 建築資訊，並建立結構分析部分資訊，以節省在結構分析時重複建置模型資訊的時間，在 IFC 資訊的存取上為使用自行撰寫的 JAVA 程式進行處理。樊啟勇(2007) 對幾種支援 IFC 的 BIM 系統進行探討與比較並針對結構設計所需結構元件如樑柱等之組成資料進行擷取，並建立結構分析相關部分資訊，在 IFC 資訊存取上為使用自行撰寫的 FORTRAN 程式處理。曾國峰(2007)以 IFC 為基礎建置一個視覺化 3D 工序模擬系統 CS3D(3D Construction Sequence Simulation System)。CS3D 使用 IFC Engine OCX 呈現 3D 模型及運用 IFCsvr API 擷取幾何物件屬性資料。能夠將建築 BIM 系統所匯出之 IFC 檔案載入系統，讓使用者利用便捷的編製、儲存與施工順序模擬功能。吳翌禎(2007) 提出了一套工程專案資訊整合管理架構，以解決工程監管單位在工程專案中所遭遇之資訊介面及資料整合管理上的問題。此研究根據所提出架構建立一視覺化專案管理系統，此系統在資訊交換上以 IFC 為基礎，並且使用 IFCsvr API 進行資料存取。

(23)

第三章

第三章 IFC 規格與實作

規格與實作

本章就 IFC 的規格(Specification)及實作(Implementaion)進行探討，規格部份包含 IFC 資訊的描述方式、物件導向於 IFC 規格運用及 IFC 規格的基礎架構；實作部份包含 IFC 建築資訊模型與模型視圖、IFC 實體檔案格式及 IFC 資訊存取應用程式介面。

3.1 IFC 資訊描述

資訊描述

資訊描述方式

方式

IFC 的規格以物件導向為基礎進行設計，運用了類別、繼承、抽象資料類型與多型等概念定義資訊，故必須有一個適合的資訊描述方式才能表達這些資訊。IAI 使用 EXPRESS 資訊塑模語言(data modeling language)作為 IFC 資訊的描述方式並定義了四種資料型態[23]，分別敘述如下:

Defined Type

用於表示基礎資料型態，包含：REAL(實數)、INTEGER(整數)、NUMBER(數字 ) 、 LOGICAL( 邏輯符號 ) 、 BOOLEAN( 布林代數 ) 、 BINARY( 位元 ) 、 STRING(字串)。Defined Type 很像使用 C/C++的 typedef，目的都在給予基礎資料型態定義一個更語意的別名(alias)。以“IfcMassMeasure”及“IfcLabel”為例，其 EXPRESS 描述如下:

TYPE IfcMassMeasure = REAL; END_TYPE;

IfcMassMeasure 為表示物品重量的 Defined Type，其基礎型態為實數(REAL)。

TYPE IfcLabel = STRING; END_TYPE;

IfcLabel 為描述文字標籤的 Defined Type，其基礎型態為字串(STRING)。

Enumeration

用於表示狀態或類型，它的值只能屬於定義的內容之一，所定義的內容將以文字型式存在。Enumeration 很像 C/C++的列舉(enum)，目的都在表示一個狀態，而且這個狀態必須為列出來的狀態之一。以“IfcBeamTypeEnum”為例，其 EXPRESS 描述如下:

(24)

TYPE IfcBeamTypeEnum = ENUMERATION OF (BEAM, JOIST, LINTEL, T_BEAM, USERDEFINED, NOTDEFINED); END_TYPE; IfcBeamTypeEnum 定義樑的類型，能夠為 BEAM(一般水平結構樑)、JOIST(用以支撐樓地板的小樑)、LINTEL(水平橫楣樑)、T_BEAM(包含樓地板的 T 型樑)、USERDEFINED(自行定義)、NOTDEFINED(未定義)。

Select Type

這是一種比較特殊的資料型態，它必須屬於內容定義的資料型態之一，與 Enumeration 不同的是，他的內容就是一種資料型態，此資料型態可以為 Defined Type 或是 Entity，而不是單純表示狀態的文字。Select Type 很像 C/C++ 的 union ，表示一個存放不同的資料型態的記憶體位置。以 “IfcSimpleValue”為例，其 EXPRESS 描述如下:

TYPE IfcSimpleValue = SELECT

(IfcInteger, IfcReal, IfcBoolean, IfcIdentifier, IfcText, IfcLabel, IfcLogical); END_TYPE; IfcSimpleValue 表示一個簡單的數值，可以是 IfcInteger(整數)、IfcReal(實數)、 IfcBoolean( 布林值 ) 、 IfcIdentifier( 字串 )、 IfcText( 字串 ) 、 IfcLabel( 字串 ) 、 IfcLogical(邏輯符號)這幾種 Defined Type 其中之一。

Entity

它是 IFC 規格中最複雜也最重要的資料型態，其可以視為物件導向的類別 (Class)，它能包含各種屬性、或是繼承其他 Entity、以及定義成抽象資料類型，並可以描述一些法則(rule)。它是 IFC 表達資訊最主要的方式，以

(25)

“IfcOrganizationRelationship”為例，其 EXPRESS 描述如下:

ENTITY IfcOrganizationRelationship;

Name : IfcLabel;

Description : OPTIONAL IfcText; RelatingOrganization : IfcOrganization;

RelatedOrganizations : SET [1:?] OF IfcOrganization;

END_ENTITY; 上例中 IfcOrganizationRelationship 用於描述組織與組織間的關係，其定義了四個屬性:Name 表示此關係的名稱，資料型態為 IfcLabel；Description 表示此關係的描述，資料型態為 IfcText；RelatingOrganization 表示關聯組織，資料型態為 IfcOrganization；RelatedOrganizations 表示與關聯組織具有此關係的其他組織，資料型態為 IfcOrganization。 Entity 屬性的資料型態必須為 IFC 定義的四種資料型態之一，若該屬性為選擇性存在則必須加上“OPTIONAL”關鍵字，如前述 Description 屬性。並且屬性也能夠以集合體存在，IFC 定義兩種集合體 SET 與 LIST 分別表示無序及有序集合體，如前述 RelatedOrganizations 為無序的 IfcOrganization 集合體。 IFC Entity 常常利用關聯屬性(Relating)與被關聯屬性(Related)來表示一對多的關係，如前述的 RelatingOrganization 與 RelatedOrganizations。除了屬性之外，Entity 能夠藉由法則進一步定義，這些法則包含:

1. 逆向法則 (Inverse Rule) ：用來表示逆向參考的關係，例如 IfcOrganization 定義兩個逆向關係: IsRelatedBy 與 Relates 表示其分別在 IfcOrganizationRelationship 的 RelatedOrganizations 與 RelatingOrganization 屬性被參考。

2. 獨特法則(Unique Rule)：用來定義屬性的唯一性，例如定義 ID 這個屬性的內容在同個資訊模型中不能重複出現。

3.衍生法則(Derive Rule)：用來表示一個虛擬屬性，此屬性是由同個 Entity 的其他屬性衍生而來，例如一個矩形斷面的面積由其長、寬計算而來。 4.領域法則(Domain Rule)：定義一個屬性的範圍，例如定義 T 型斷面的翼板寬度必須大於腹板寬度。

3.2 物件導向於

物件導向於

物件導向於 IFC 規格

規格

規格運用

運用

本節介紹 IFC 規格在設計上如何運用物件導向的概念包括繼承、抽象資料類型與多型。

(26)

3.2.1 繼承

繼承

IFC 定義 Entity 能夠繼承自其他 Entity，但只限於單一繼承(Single Inheritance)，也就是無法同時繼承自多個 Entity，但可同時被其他多個 Entity 繼承，此外 Entity 繼承關係同樣遵循了“重力原則”，IFC 規定各層級的 Entity 只能繼承(被繼承)相同層級的 Entity 或低於此層級的 Entity，例如資源層的 Entity 無法繼承核心層的 Entity。IFC 規格設計上運用了許多繼承，藉由繼承使得規格更容易擴充與維護，以 “IfcAddress” 、 “IfcPostalAddress” 、 “IfcTelecomAddress” 三個 Entity 的繼承關係為例進行說明如下。 IfcAddress 的 EXPRESS 描述如下: ENTITY IfcAddress

Purpose : OPTIONAL IfcAddressTypeEnum;

ABSTRACT SUPERTYPE OF(ONEOF(IfcPostalAddress,IfcTelecomAddress)) Description : OPTIONAL IfcText;

UserDefinedPurpose : OPTIONAL IfcLabel; END_ENTITY;

IfcAddress 定義“位址”的基本資料，它有三個屬性:Purpose 表示位址的意義，可能是住家(HOME)或是工址(SITE)等；Description 描述這個位址的資訊； UserDefinedPurpose 自行定義位置的意義。此 Entity 藉由 ABSTRACT 關鍵字定義為抽象資料類型，並由 SUPERTYPE OF 關鍵字得知為 IfcPostalAddress、 IfcTelecomAddress 的父類別(Super Class)，它同時被兩個 Entity 所繼承。 IfcPostalAddress 的 EXPRESS 描述如下：

ENTITY IfcPostalAddress SUBTYPE OF (IfcAddress );

InternalLocation : OPTIONAL IfcLabel;

AddressLines : OPTIONAL LIST [1:?] OF IfcLabel; PostalBox : OPTIONAL IfcLabel;

Town : OPTIONAL IfcLabel; Region : OPTIONAL IfcLabel; PostalCode : OPTIONAL IfcLabel; Country : OPTIONAL IfcLabel;

(27)

IfcPostalAddress 用 SUBTYPE OF 關鍵字表示其繼承自 IfcAddress，除了定義了自己的屬性外，其額外擁有 IfcAddress 的所有屬性，它進一步擴展“位址” 的內容為 “ 郵件位址 ” 。它定義了幾個描述這個 Entity 的屬性，如： InternalLocation 表示其內部位置，可能是某個樓層或是房間編號； AddressLines 表示郵件地址；Town 表示位址所在的城市，可能是某個鄉鎮； Region 表示位址所在的區域，可能是某個省份或是縣市；PostalCode 為該位址的郵遞區號；Country 為該位址所在的國家。 IfcTelecomAddress 的 EXPRESS 描述如下： ENTITY IfcTelecomAddress SUBTYPE OF (IfcAddress );

TelephoneNumbers : OPTIONAL LIST [1:?] OF IfcLabel; FacsimileNumbers : OPTIONAL LIST [1:?] OF IfcLabel; PagerNumber : OPTIONAL IfcLabel;

ElectronicMailAddresses : OPTIONAL LIST [1:?] OF IfcLabel; WWWHomePageURL : OPTIONAL IfcLabel;

END_ENTITY;

由上述 SUBTYPE OF 關鍵字得知 IfcTelecomAddress 同樣繼承自 IfcAddress，除了自己定義的屬性外，其也擁有 IfcAddress 的所有屬性，它進一步將“位址” 的內容擴展為“通信位址”。它定義幾個描述這個 Entity 的屬性，如： TelephoneNumbers 為該位址的電話號碼；FacsimileNumbers 為該位址的傳真號碼；ElectronicMailAddresses 為電子郵件位址；WWWHomePageURL 為網頁位址。 IFC 規格在設計上運用了許多如上述範例的繼承關係進行擴充 Entity 的內容，當規格需要修正時也能藉由修改部份的 Entity 進而影響其子類別，在規格的維護上較為方便。

3.2.2 抽象資料類型

抽象資料類型

抽象資料類型與多型

與多型

IFC Entity 可被定義為抽象資料類型，這種類型的 Entity 只能被繼承而無法成為物件，它通常用於描述一個共同的概念(Common Concept)，抽象資料類型可以視為所有子類別(Sub Class)的共通介面，對於參考它的 Entity 而言只要了解它具有這些介面，因此藉由抽象資料類型能夠達到多型的效果，被參考時實際上必須以非抽象資料類型的子類別存在。前面提到的“IfcAddress” 即是一種抽象資料類型，它被“IfcOrganization”參考。

(28)

IfcOrganization 的 EXPRESS 描述如下：

ENTITY IfcOrganization;

Id : OPTIONAL IfcIdentifier; Name : IfcLabel;

Description : OPTIONAL IfcText;

Roles : OPTIONAL LIST [1:?] OF IfcActorRole; Addresses : OPTIONAL LIST [1:?] OF IfcAddress;

END_ENTITY;

IfcOrganization 的 Addresses 屬性資料型態為 IfcAddress，但由於其為抽象資料型態，實際上被參考可能是“IfcPostalAddress”或“IfcTelecomAddress”這兩個非抽象子類別。再以“IfcExtrudedAreaSolid”這個常被用來描述建築元件形狀的 Entity 為例，其 EXPRESS 描述如下: ENTITY IfcExtrudedAreaSolid END_ENTITY; SUBTYPE OF ( IfcSweptAreaSolid); ExtrudedDirection : IfcDirection; Depth : IfcPositiveLengthMeasure; 它所代表的形狀為一個二維的斷面往指定的方向伸展固定的長度，如圖 3-1， ExtrudedDirection 表示伸展的方向；Depth 為伸展的長度。由 SUBTYPE OF 關鍵字得知其繼承自 IfcSweptAreaSolid 這個 Entity，其 EXPRESS 描述如下: ENTITY IfcSweptAreaSolid

ABSTRACT SUPERTYPE OF (ONEOF(IfcExtrudedAreaSolid, IfcRevolvedAreaSolid, IfcSurfaceCurveSweptAreaSolid)) SUBTYPE OF ( IfcSolidModel); SweptArea : IfcProfileDef; Position : IfcAxis2Placement3D; END_ENTITY; IfcSweptAreaSolid 的 SweptArea 屬性用來表示這個形狀的斷面，資料型態為 IfcProfileDef(Entity)，其 EXPRESS 描述如下:

(29)

ENTITY IfcProfileDef

ABSTRACT SUPERTYPE OF (ONEOF(IfcParameterizedProfileDef, IfcArbitraryOpenProfileDef,

IfcArbitraryClosedProfileDef, IfcCompositeProfileDef, IfcDerivedProfileDef)); ProfileType : IfcProfileTypeEnum;

ProfileName : OPTIONAL IfcLabel;

END_ENTITY;

由 ABSTRACT 關鍵字得知它是一個抽象資料類型，ProfileType 屬性定義斷面類型；ProfileName 屬性表示斷面名稱。由於它是抽象資料類型，當 IfcExtrudedAreaSolid 藉由 SweptArea 屬性參考這個 Entity 時實際上是參考繼承 IfcProfileDef 的非抽象子類別。IfcProfileDef 繼承關係如圖 3-2，實際上被參考的 Entity 可能是繼承它的 IfcIShapeProfileDef(描述 I 型斷面 ) 或是 IfcCircleProfileDef(描述圓形斷面)等非抽象子類別。

3.3 IFC 規格基礎

規格基礎

規格基礎架構

架構

在 IFC 架構的內核層(Kernel Layer)與產品延伸層(Product Extension)定義了一些基礎 Entity，它們對於 IFC 規格有相當重要的意義，所有此層以上的 Entity(除了資源層外)都是繼承自這些關鍵的 Entity。整理這些基礎 Entity 繼承關係及所屬層級如圖 3-3，以 IfcRoot 為頂點，藉由繼承擴展 Entity 的內容，以下由繼承關係介紹這些基礎 Entity 制定的意義以及其重要的子類別。

IfcRoot

它是一個抽象資料類型，也是繼承的頂點，除了資源層以外的 Entity 都具有 IfcRoot 的身分。就如同 JAVA 或是.Net Framework 類別庫中的 Object 類別，它主要的功能在於提供物件辨識、物件擁有權、變更歷史，以及名稱與敘述。 GlobalId 這個屬性在 IFC 資訊模型範圍內必需是唯一，其可當作 Entity 物件的索引。

IfcObjectDefinition

它繼承 IfcRoot，同樣是抽象資料類型，所有物體及事件都具有這個身份。它定義了四個逆向關係:

1. HasAssignments

表示此 Entity 能夠藉由 IfcRelAssigns 指定給其他 Entity，例如把一些工作指定給某家包商。

(30)

2. IsDecomposedBy

表示此 Entity 能夠藉由 IfcRelDecomposes 被分解，例如一個樑柱接頭可以分解成許多結構元件。

3. Decomposes

表示此 Entity 能夠藉由 IfcRelDecomposes 組成其他 Entity，其為組成其他 Entity 的部件。

4. HasAssociations

表示此 Entity 能夠藉由 IfcRelAssociates 與其它 Entity 產生關聯，例如一種材料可能被用在許多構件上。繼承它的類別有: IfcResource:用以描述建築生命週期中牽涉到的資源，如機具、人力。 IfcProject:用以描述建築專案相關資訊，如單位、座標系統。 IfcProduct:用以描述一個具有形狀與位置屬性的物件，如樑、柱。 IfcProcess:用以描述一個行程，如規劃行程、設計行程。 IfcGroup:用以描述群組集合，如將產品分為“已完成”與“未完成”。 IfcControl:用以描述管理，如描述一件工作的時間表。 IfcActor:用以描述組織人員的角色，如將一個組織設定為業主。

IfcRelationship

它繼承自 IfcRoot ，用來描述 Entity 與 Entity 之間的關係，只要具有 IfcRelationship 身分的 Entity 命名都是以“IfcRel”做開頭。IfcRelationship 是一個抽象資料類型，本身沒有任何屬性，它分別被 IfcRelAssigns 、 IfcRelDecomposes、 IfcRelAssociates、 IfcRelDefines、IfcRelConnects 繼承，這五個 Entity 定義了 IFC Entity 之間五個主要的關係:

1. IfcRelAssigns 用來定義指定的關係，將一組 Entity 指定給一個特定的 Entity。繼承他的 Entity 有: IfcRelAssignsToProcess，指定行程；IfcRelAssignsToProduct，指定產品；IfcRelAssignsToControl，指定管理；IfcRelAssignsToResource，指定資源；IfcRelAssignsToActor，指定人員；IfcRelAssignsToGroup，指定群組。 2. IfcRelDecomposes 用來定義分解、組合的關係，定義一組 Entity 組成一個 Entity 。 IfcRelAggregates 子類別用來描述物體的分解組合，例如一個工程專案由可以由好幾個工址組成。 3. IfcRelAssociates 用來建立 Entity 間關聯的關係，定義一組 Entity 關聯到一個特定的 Entity ，重要的子類別有 : IfcRelAssociatesMaterial ，材料關聯；

(31)

IfcRelAssociatesDocument，文件關聯。 4. IfcRelDefines 用來將一組 Entity 給予一個定義屬性或是類型。重要的子類別有: IfcRelDefinesByProperties，定義屬性；IfcRelDefinesByType，定義類型。 5. IfcRelConnects 用來定義 Entity 間連結的關係，這些連結通常都是用在特定的地方。 IfcRelContainedInSpatialStructure 子類別定義一組佔有空間的物體(樑、柱、牆等)連接到一個空間容器 Entity(樓層、建築物等)。

IfcPropertyDefinition

具 IfcPropertyDefinition 身分的 Entity 用所有的屬性來描述一個特性。而這些特性大多屬於特定領域，例如: IfcDoorPanelPropertiesd 子類別用來描述門開口的方式。其中 IfcPropertySet 是一個能夠藉由一組 IfcProperty 自己定義一個屬性，例如能夠自定義一個描述“舒適度”的 IfcPropertySet，那可能就必須擁有溫度、溼度、風速等 IfcProperty。

3.4 IFC 建築資訊模型

建築資訊模型

建築資訊模型與模型視圖

與模型視圖

制定 IFC 規格的目的在於實現 BIM 資訊交換的精神。將建築物整個生命週期的資訊利用 IFC 描述成建築資訊模型，並運用於資訊交換稱為 IFC 的實作。本節內容包含基礎 IFC 建築資訊模型與模型視圖。

3.4.1 基礎

基礎

基礎 IFC 建築資訊模型

建築資訊模型

一個基礎的 IFC 建築資訊模型有幾個 Entity，包含:IfcProject、IfcSite、 IfcBuilding、IfcBuildingStorey 及建築元件，其關係如圖 3-4，分別介紹如下:

IfcProject

表示一個建築專案的相關資訊，它為 IFC 建築資訊模型最上層的 Entity，每個模型必須且只能擁有一個 IfcProject。它定義了幾個重要資訊: 預設單位(例如設定長度的單位為公尺)、世界座標系統(絕對座標)、數值的精確度。

IfcSite

表示一個工址的相關資訊，包含包含其位置(相對於絕對座標)，位址的地形描述、經緯度及高程、郵件地址。IfcProject 與 IfcSite 為組合與分解關係，使用 IfcRelAggregates 描述，一個 IfcProject 能夠由許多個 IfcSite 組成。

(32)

IfcBuilding

表示一棟建築物的相關資訊，包含其位置(相對於 IfcSite 的位置)、外觀、建築物高度等資訊。IfcSite 與 IfcBuilding 為組合分解關係，使用 IfcRelAggregates 描述，一個 IfcSite 能夠由許多個 IfcBuilding 組成。

IfcBuildingStorey

表示一個樓層的相關資訊，包含位置(相對於 IfcBuilding 的位置)、外觀、樓層高(相對於 IfcBuilding 的高度)。IfcBuilding 與 IfcBuildingStorey 為組合分解關係，使用 IfcRelAggregates 描述，一個 IfcBuilding 能夠由許多個 IfcBuildingStorey 組成。

IfcBuildingElement

定義一個具有實體建築元件，它是一個抽象資料類型，所有 Share Building Elements( 資訊交換層 ) 的 Entity 都是他的子類別，包含 : IfcBeam( 樑 ) 、 IfcColumn(柱)、IfcMember(桿件)、IfcDoor(門)、IfcWall(牆)、IfcSlab(板)、 IfcStair( 樓梯 ) 、 IfcRoof( 屋頂 ) 、 IfcPile( 樁 ) 、 IfcFooting( 基礎 ) 等。 IfcBuildingElement 與 IfcSite、IfcBuilding、IfcBuildingStorey 為空間連結關係，使用 IfcRelContainedInSpatialStructure 描述其關係。

IfcSite、IfcBuilding、IfcBuildingStorey 都繼承自 IfcSpatialStructureElement，它們可以用 CompositionType 屬性將其進一步分解，這個屬性有三個狀態 “COMPLEX”、“ELEMENT”、“PARTIAL”，狀態為 COMPLEX 的 Entity 能夠分解成狀態為 ELEMENT 的 Entities；狀態為 ELEMENT 的 Entity 能夠分解成成狀態為 PARTIAL 的 Entities，如圖 3-5，ID 為#4 的 IfcBuilding 其 CompositionType 屬性為 ELEMENT ， ID 為 #6 、 #7 的 IfcBuilding 其 CompositionType 屬性為 PARTIAL，故 ID 為#4 的 IfcBuilding 可以藉由 IfcRelAggregates 表示其由 ID 為#4 及#6 的 IfcBuilding 所組成。

3.4.2 模型視圖

模型視圖

IFC 的規格涵蓋了 AEC/FM 領域，若對建築資訊模型沒有一個共同的視圖(view)很難達到資料交換的目的，以交換圖形資料為例: 一個軟體可以用點與線的 Entity 描述一個物品的外觀，而另一個軟體則是用一個參數化的 Entity 來描述，他們要進行資訊交換時還必需做轉換，所以定義共同的模型視圖 (Model View)是資訊交換的第一步。IAI 提供基本驗證的方式即是判斷軟體的輸入及輸出是否符合軟體廠商提供的模型視圖，然而一個軟體的輸入或輸出完成驗證，但資訊不能在其它軟體分享則沒有多大意義，樊啟勇(2007)做過相關的 IFC 資訊交換的研究，即使通過 IFC 認證的軟體資訊交換的效率也是

(33)

很差。故 IAI 提出 IDM(Information Delivery Manual)[24]與 MVD(Model View Definition)[25]供軟體廠商實作 IFC 時參考。 IDM 目的在將建築專案分解為許多流程(process)，定義該流程所需的資訊與輸出的資訊，以及定義流程與流程間之的資料流以建立流程地圖(process map)，以釐清資訊交換的模型視圖。例如:結構分析這個流程需要桿件、節點、載重資料、材料性質，輸出節點位移的資料；進行估價的資料需要建築物設計與材料價單。目前 IDM 還屬於制定階段，許多流程都尚未完備，這部份可能要讓各大軟體廠商共同協商制定應是比較可行的。 MVD 提供一套定義模型視圖的方法論，包含模型視圖的描述格式、描述程序、及描述工具，IAI 官方網站有提供一些範本。MVD 目的在讓大家共同一種方式描述 IFC 建築資訊模型，如同使用 UML 進行物件導向設計。

3.5 IFC 實體檔案格式

實體檔案格式

為了讓使用 IFC 描述的資訊模型能夠在軟體間進行資訊交換，故需要一個電子檔案格式用於描述資訊模型。目前 IFC 的建築資訊模型有兩種主要的電子實體檔案格式: STEP 實體檔案(STEP Physical File)及 ifcXML 格式，市面上支援 IFC 的軟體主要以 STEP 實體檔案為主，亦為本研究使用的格式。實體檔案副檔名為 ifc，是以文字形式存在，主要分為兩個部份:標頭部份(Header) 與資料部份(Data)。標頭部份包含一些檔案的基本資料，有檔案敘述、作者、 IFC 版本等資料；資料部份則是建築資訊模型的實體。雖然檔案可以直接用文字編輯軟體開啟，但是當檔案很大時物件關係會相對的複雜，能用 G.E.M. Team Solutions[26]開發的 IfcQuickBrowser 方便查找檔案。以 IfcProject 為例，其實體檔案格式描述如下: #97=IFCPROJECT('XYqLQNXnM0Wv+J5Xw/NdbQ',#107,$,$,$,$,$,(#96),#101); #107=IFCOWNERHISTORY(#106,#102,.READWRITE.,.NOCHANGE.,0,$,$,0); #106=IFCPERSONANDORGANIZATION(#105,#104,$); #105=IFCPERSON($,$,'Pingting', $,$,$,$,$); #104=IFCORGANIZATION($,$,$,(#103), $); #103=IFCACTORROLE(.ENGINEER.,$,$); #102=IFCAPPLICATION(#104,'0.1','project','54967'); #96=IFCGEOMETRICREPRESENTATIONCONTEXT('Pingting','Null',3,0.,#82,$); #82=IFCAXIS2PLACEMENT3D(#71,#63,#64);

(34)

#71=IFCCARTESIANPOINT((0.,0.,0.)); #63=IFCDIRECTION((0.,0.,1.)); #64=IFCDIRECTION((1.,0.,0.)); #101=IFCUNITASSIGNMENT((#98,#99,#100)); #98=IFCSIUNIT(.LENGTHUNIT.,$,.METRE.); #99=IFCSIUNIT(.AREAUNIT.,$,.SQUARE_METRE.); #100=IFCSIUNIT(.PLANEANGLEUNIT.,$,.RADIAN.);

Entity 的表示法為 “#Number = EntityName(Attribute1, Attribure2, …);”，每個數字代表 Entity 物件的 ID，當 Entity 之間互相參考時即是使用這個符號，例如上述#97(IfcProject)的 OwnerHistory 屬性的内容為#107(IfcOwnerHistory)。 Defined Type 與 Enumeration 資料型態的屬性內容都直接以文字表示，例如上述#97(IfcProject)的 GlobalId(IfcGloballyUniqueId – DefinedType)屬性的內容為'XYqLQNXnM0Wv+J5Xw/NdbQ'；#103(IfcActorRole)的 Role(IfcRoleEnum) 屬性為內容為.ENGINEER.。對於 OPTIONAL 屬性，若其內容不存在，則使用“$”符號代替。

3.6 IFC 資訊存取應用程式介面

資訊存取應用程式介面

目前已經有不少 IFC 資訊存取的應用程式介面(API)，能夠使用程式語言呼叫這些 API 進行擷取及建立 IFC 檔案的資訊。在 IAI 官方網站[3]有列出許多開發工具，但大部分皆為商業軟體。為了方便進行學術研究 IFC 應用，本研究嘗試使用兩種兩種免費且容易取得的 API，IFCsvr 與 IFCEngineDLL，了解其對 IFC 檔案資訊存取的方式，各分別介紹於下面章節。

3.6.1 IFCsvr

IFCsvr 由 SECOM[27]公司開發，其核心為商業軟體 ST-Developer[28]，目前最新版本為 R300 支援到 IFC2x3。IFCsvr 提供一個機制存取/建立 IFC 實體檔案與 ifcXML。其為 ActiveX DLL 元件，能在 Windows 平台藉由 COM(Component Object Model)介面使用此軟體元件，使用此元件前必須先向作業系統登錄，理論上支援 COM 技術的程式語言皆可使用(Visual Basic 6.0、 Visual C++ 6.0、VBA、.NetFramework 程式語言等)。IFCsvr 架構如圖 3-6，其分為幾個物件，分別介紹如下 :

IFCsvr.R300

此物件控制 IFC 實體檔案的開啟與新增，使用 OpenDesign 方法開啟 IFC 檔案並產生 Design 物件；使用 NewDesign 方法建立 IFC 檔案並產生 Design 物件。

(35)

Design

此物件代表整個 IFC 實體檔案的建築資訊模型，包含所有的 Entity，其只能由 IFCsvr.R300 物件產生， Design 提供方法尋找 Entity 及 Entities 物件 :FindObject 、 FindObjects 、 FindObjectsByValue 、 FindObjectByP21Id 、 FindObjectByName；使用 Add 方法能夠新增 Entity 到 Design；用 Save 方法將 Design 的資料寫入 IFC 實體檔案。

Entities

此物件為 Entity 物件的集合體，必須由 Design 尋找 Entity 的方法取得，由 Count 屬性能夠得知其大小；使用 Item 方法可取得 Entity 物件。

Entity

此物件代表 IFC 建築資訊模型中的一個 Entity，它必須由 Design 物件尋找或新增 Entity 的方法、Entities 物件的 Item 方法或從 Attribute 物件取得。使用 Delete 方法可以將此 Entity 自 Design 中刪除；藉由 GetUsedIn 這個方法能夠找到參考它的 Entity; 其 Attributes 屬性可以取得 Attributes 物件。

Attributes

此物件為一個 Entity 所有屬性的集合，Count 屬性可以得知屬性的數量；使用 Item 方法能夠取得某 Attribute。

Attribute

此物件為 Entity 的某一個屬性，必須由 Attributes 的 Item 方法取得。當此屬性非集合體(SET、LIST)時用 Value 屬性取得或設定其值；若為集合體則用 GetItem 方法取得其內容，用 SetItem 方法設定其內容。

以下使用 VB.net 示範如何使用 IFCsvr 建立一個 IFC 檔案與 IfcPerson Entity。

Private svr AsNew IFCsvr.R300 Private design As IFCsvr.Design

design = svr.NewDesign("C:\sample.ifc", "IFC2x3") Dim Person As IFCsvr.Entity

Person = design.Add("IfcPerson") Person.Attributes("ID").Value = "001"

Person.Attributes("GivenName").Value = "Pingting" Person.Attributes("FamilyName").Value = "Shen" design.Save()