應用IFC記載建築技術規則檢測資訊之研究—建築設計施工編第1、2章

235  Download (0)

全文

(1)

應用 IFC 記載建築技術規則檢測資訊之

研究—建築設計施工編第 1、2 章

內 政 部 建 築 研 究 所 委 託 研 究 報 告

中華民國 106 年 12 月

(2)
(3)

科技部GRB 編號:PG10601-0615 計畫編號:106301070000G0023

應用 IFC 記載建築技術規則檢測資訊之

研究—建築設計施工編第 1、2 章

受委託者:中華民國公共工程資訊學會

計畫主持人:施宣光

共同主持人:嚴國雄

研 究 助 理 :葉俞杰、杜京霞

研 究 期 程 : 中 華 民 國

1 0 6 年 2 月 至 1 0 6 年 1 2 月

研 究 經 費 : 新 台 幣

1 5 4 萬 6 0 0 0 元

內 政 部 建 築 研 究 所 委 託 研 究 報 告

中華民國 106 年 12 月

(本報告內容及建議,純屬研究小組意見,不代表本機關意見)

(4)
(5)

I

目次

表次 ... III

 

圖次 ... V

 

摘要 ... VII

 

ABSTRACT ... XV

第一章 緒論 ... 1

 

第一節

研究緣起 ... 1

 

第二節

研究背景 ... 3

 

第三節

研究方法 ... 6

 

第二章 國內外相關文獻探討 ... 14

 

第一節

IFC 交換格式檔案 ...

16

 

第二節

國內外有關本案之研究情況 ... 24

 

第三章 應用 IFC 記載建築法規資訊 ... 28

 

第一節

法規資訊結合 IFC 格式 ... 28

 

第二節

法規分析架構 ... 39

 

第三節

應用標準化法規模型於建築管理的模式 ... 43

(6)

第四章 法規分類與檢討 ... 48

 

第一節

檢討方法分類說明 ... 48

 

第二節

法規分析與檢測程序關係 ... 51

 

第五章 結論與建議 ... 56

 

第一節

結論 ... 56

 

第二節

建議 ... 57

 

附錄一、研究團隊工作會議紀錄 ... 62

 

附錄二、專家座談會議記錄 ... 82

 

附錄三、法規名稱標準化架構圖 ... 94

 

附錄四、建築技術規則-建築設計施工編第 1、2 章 法規分析檢討

表 ... 100

 

附錄五、期中審查會議記錄與意見回覆 ... 167

 

附錄六、期末審查會議紀錄與意見回覆 ... 187

 

參考書目 ... 208

 

(7)

III

表次

表 1 建築技術規則設計施工編第 2 章分析架構表 ... 42

 

表 2 元件屬性讀取運算邏輯分析表 ... 48

 

表 3 元件之間關係運算邏輯分析表(停車位計算) ... 49

 

表 4 非特定範圍元件屬性取得邏輯分析表 ... 50

 

(8)
(9)

V

圖次

圖 1-1 IFC Schema 應用與 MVD 編定架構 ... 8

 

圖 1-2 模型法規資訊整合交換的發展與使用 ... 10

 

圖 2-1 四種類型的法規檢查演進架構圖 ... 15

 

圖 2-2 使用 IFC server ActiveX component 驗證預製混凝土的

MVD 架構 ... 16

 

圖 2-3 IFC 系統架構表 ... 19

 

圖 2-4 IFCSpce 與 IFCDoor 物件屬性(Attributes)資料表 .. 20

 

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

 

圖 2-6 MVD 應用描述公版 ... 24

 

圖 2-7 IFC、IFC 與 IDM 資料架構圖 ... 25

 

圖 2-8 法規檢測的基礎流程架構 ... 26

 

圖 3-1 法規邏輯化分析程序 ... 28

 

圖 3-2 以 IFC 呈現法規分析架構 ... 29

 

圖 3-3 法規屬性分類 IFC 架構 ... 29

 

圖 3-4 專案及建築基地相關物件圖解(範例) ... 30

 

圖 3-5 停車位與門之關聯圖示 ... 31

 

圖 3-6 防火門屬性參數關係圖示 ... 32

 

圖 3-7 車位與車道關係模型圖示 ... 33

 

(10)

圖 3-8 車道定義模型圖示 ... 34

 

圖 3-9 廣場式開放空間圖示 ... 35

 

圖 3-10 法規樣版面積檢測設定圖示 ... 36

 

圖 3-11 法規樣版停車位元件相關參數說明圖示 ... 37

 

圖 3-12 本案法規分析與雙北法規樣版架構關係圖 ... 38

 

圖 3-13 建築設計的 IFC 架構 ... 39

 

圖 3-14 IFC 層級架構範例 ... 41

 

圖 3-15 法規標準化後建築管理程序架構圖 ... 43

 

圖 3-16 法規參數標準化定義之法規樣版 ... 44

 

圖 3-17 出圖連動製圖相關資訊 ... 45

 

圖 3-18 圖台顯示審查相關資訊-空間與色彩計畫 ... 46

 

圖 3-19 圖台顯示審查相關資訊-尺寸資訊 ... 46

 

圖 4-1 法規分析與檢測系統程序關係圖 ... 52

 

圖 4-2 選擇元件 IFCSLAB(樓板) ... 53

 

圖 4-3 選擇元件 IFCSTAIR(樓梯) ... 53

 

圖 4-4 產生虛量體(樓梯踏階面產生 190 公分虛量體) ... 54

 

圖 4-5 進行碰撞檢查 (虛量體與樓板進行交集碰撞檢查) ... 54

 

圖 4-6 輸出訊息(通過與不通過訊息說明) ... 55

 

(11)

VII

摘要

關鍵詞:建築技術規則、自動化檢測、模型視圖定義、建築資訊建模 一、研究緣起 自動化規則檢測是BIM 技術發展的相當重要的領域,它是 BIM 建築模型 資料化的核心技術,核心關鍵點與應用場域就是建築法規的檢測。臺北市政府 自2009 年啟動了以 BIM 技術輔助建造執照法規查核的可行性研究,俟後新北 市政府於2012 一開始進行 BIM 法規檢測系統開發的計畫。從 2012 年到 2014 年歷經3 年時間,開發了國內第一個以建築技術規則為主軸的建築執照輔助查 核系統,並成功的應用在超過 26 個公共建築的案例上,建築物的使用類型包 含集合住宅、運動中心、醫院、辦公大樓等各種不同類型的建築物。 本計畫希望以臺北市、新北市政府成功開發法規查核系統的經驗為基礎, 延伸既有的研究成果到全國之一體適用,我們以建築技術規則建築設計施工編 第 1、2 章法規名詞基本定義與一般設計通則條文做為法規檢測分析的起點, 透過 Industry Fundation Classes(簡稱 IFC)資料交換格式(本文討論以 IFC2x3 為基準)綱要(schema)分析法規名詞的元件分類與並討論與 Model View Definition(簡稱 MVD)模型視圖架構的資料連結。建立建築技術規則檢測資料 共享的共通格式,讓既有的成果可以進一步推廣到全國各縣市政府,並在法規 檢測領域提供具體研究成果供世界各國政府參考。 二、研究方法與過程 本計畫的研究方法將採用行動研究的方式並與開業建築師合作,提供樣版 協助其設計團隊建立能夠符合法規查核標準的資訊模型,藉助其實際操作經驗 與回饋,並取得共識以建立建築技術規則檢測資訊的共通標準。同時也針對國 外相關研究方法與內容進行探討,以此確定本案之研究方法符合IFC 架構與方 法,研究過程也加入程式開發之實務經驗進行探討,將分析出之法規運算邏輯 以程式開發的方式呈現,以驗證分析結果確實可執行。

(12)

三、重要發現

C.Eastman(2009)對於法規檢測的發展歷史做了一次完整的描述與階段性 的成果調查。內容涵蓋了政府部門發展的專案計畫(如新加坡 BCA 部門發展的 e-plan check)與挪威所發展出來的商用軟體(如 Solibri Model checker),可見法規 檢測的發展可用於政府部門也可用於民間的軟體開發。臺北市政府都市發展局 在2009 年啟動 BIM 的研究計畫,這篇文章成為臺北市擬定國內 BIM 法規檢測 研究計畫方針的重要參考依據;此外,它也是各國研究法規檢測必讀的重要參 考文獻(例如韓國在 2013 年啟動的七年(2013-2019)法規檢測研究計畫)。後續, 在2015 年,Solihin & Eastman 針對法規檢測可以發展的類型提出四個分類(詳 第 2 章),法規檢測可以發展的方向與需要具備的條件,在這篇文章已經有完 整的敘述。 國內目前的法規檢測發展屬於實際操作與系統建置的階段。相關研究理論 基礎以參考C.Eastman 的研究文獻為主,再參酌其他相關學者的研究著作。而 內政部建築研究所102 年「BIM 導入建築管理行政作業法規調查研究」案是相 當詳實的基礎調查報告,所提列的發展方向也是目前臺北市、新北市政府發展 法規檢測的參考架構。從國內外文獻可以發現一個共通的特點就是:法規檢測 之語意辭典(IFD)、法規參數的轉譯、共通資料交換格式(IFC)、標準化的作業 環境(MVD),是法規檢測發展的四要素。本次研究所著重的就是法規語意辭典 的基礎建置工作 IFC 之所以被認可為一種共通的資料交換格式,可歸功於國際標準組織 (ISO International Standard Organization ) 所 制 定 的 STEP ( Standard for Exchange of Product model data)以及 IAI 組織(International Alliance for Interoperability)努力的結果。在許多的文獻都提到,過去的 2D、3D 商業繪圖 的發展趨勢,只是著重於繪圖與圖像效果的呈現,圖就只是一張圖而無資料的 附加;但在 BIM 的作業環境下,模型所附加的資訊成為一項主要的工作,且 各國繪圖作業環境不同,專案資訊需求也不同。透過國際Building Smart 組織 這些年的努力,IFC 格式成為一個共同可接受的資料格式,這就是為什麼本次 研究要針對IfcObjects 與 IfcSpace 進行名詞對應的主因。而國際間 BIM 相關商

(13)

IX

業軟體要為各國所採用,必須遵守IFC 的資料格式對軟體構件進行命名,目前 的商業軟體的檔案匯出格式以支援Ifc2x3 版本為主。

從Solihin & Eastman(2015 年)的法規檢測研究分類來看,是屬於通則性的 分類方式。本次研究是針對可運算程度,再進一步細分,如此的做法主要考量 國內法規的書寫型態與中文化的語意架構有時不如英文清楚。再者,國內的法 規檢討模式確實比國外複雜,例如在容積檢討上,國外只有總樓地面積的觀 念,而國內則有計入、免計、免計容積上限檢討等。每多一項條件,邏輯檢討 會從單向變為雙向甚至多向的反覆檢討模式。因此本研究的分類成果再分類 1 與分類2 與 Solihin & Eastman 的法規檢測研究分類 1(基本資料)、分類 2(程式 計算)相近,皆是以討論基本單向運算的法規為主。分類 3 與分類 4 則著重在 空間幾何碰撞與地理資訊(GIS)的整合運算。藉此,希望在後續的研究上可以討 論BIM 與 GIS 整合運算的通用標準。 本次研究成果是一項基礎紮根的工作,同時期許國內的法規檢測研究成果 可與國際接軌。因此將參照IFC 階層與屬性資料架構研訂法規檢測所需之基本 物件定義、關聯架構等,以作為法規資訊交換MVD 基礎。同時接續現有國內 既有的成果,避免行政資源重複浪費,因此以新北市所提出之法規樣版檔為參 考架構,深化它的基礎資料編定,法規檢測樣版檔與檢測系統平台更具全國一 致的通用性,協助台北市、新北市以外的開業建建築師(如桃園市、臺中市等) 在其設計方案過程中,可以先行法規檢討的評估,以提升設計品質與效率。在 本案中將此一基礎研究編定完整的說明:「法規名稱標準化架構」(附錄三)是 將法規名詞定義與 IFC 架構做完整對應;「建築技術規則-建築設計施工編第 1、 2 章 法規分析檢討表」(附錄四)是針對法規做了運算邏輯的分析,並與 IFC 架構進行對應,這研究成果將幫助未來深化建築資訊應用的一個基礎。 四、主要建議事項 本研究計畫過程中,獲致二項立即可行建議及三項中長期建議: 建議一 立即可行之建議:持續建築技術規則設計施工篇應用IFC 記載建築技術規

(14)

則檢測資訊研究 主辦機關:內政部建築研究所 協辦機關:內政部營建署、臺北市政府都市發展局、新北市政府工務局、 桃園市政府建築管理處、中華民國公共工程資訊學會 建議依據本次研究所提出法規邏輯分析的兩個重要關鍵要素:法規名 稱標準化、法規運算邏輯方式標準化,以及本報告今年度針對建築技術規 則設計施工篇第 1、2 章之研究成果為基礎,持續針對建築技術規則施工 篇其他章節繼續分析研究,以持續建立我國建築法規標準化之基礎標準。 本次專案所應用國際通用標準IFC 格式進行法規邏輯化的記載,不同的應 用軟體皆可應用此國際標準應用發展符合我國建築法規規範的應用工具 或功能。 本案成果中也將提供符合上述標準的測試性法規輔助檢測平台進行 應用測試,建議執行單位中華民國公共工程資訊學會持續參與法規邏輯化 分析工作並將其應用於法規輔助檢測平台與法規樣版之調整,為我國執行 法規檢測建立完整的基礎。此測試性平台也可提供給有意願發展 BIM 應 用於建築法規輔助檢測之縣市政府(例如:桃園市政府)進行測試使用,希 望能鼓勵並擴大參與法規標準化研究與輔助檢測之落實。 建議二 立即可執行之建議:整合法規樣版推行國內通用可執行之法規標準參數樣 版 主辦機關:內政部建築研究所、新北市政府工務局 協辦機關:內政部營建署、臺北市政府都市發展局、桃園市政府建築管理處、 中華民國全國建築師公會、臺北市建築師公會、新北市建築師公會、桃園市 建築師公會、中華民國公共工程資訊學會 本次研究案之成果可結合新北市政府所提出之完整並經過實務應用

(15)

XI 經驗的法規樣版標準,此樣版屬性參數後,並推廣至其他地方政府,如臺 北市、桃園市等。並將目前執行之案例進行整理後提供教學參考,以利建 築資訊建模應用於建築設計檢討時相關範例參考。 建議三 中長期之建議:建立人機整合的電腦輔助查核機制,解決一致性與跨域整 合的綜合性法規審查議題 主辦機關:內政部建築研究所、內政部營建署 協辦機關:臺北市建築管理工程處、新北市政府工務局、桃園市政府建築 管理處 從本次的研究範圍對 IFC 資料架構進行深入探討之後發現,現行的 IFC2x3 資料架構,以實體構件(IfcObjects)與空間名稱(Ifcspace)建構建築物 的 本 體 資 訊 , 並 以 空 間 關 係(IfcRelContainedInSpatialStructure) 連 結 IfcObjects 與 Ifcspace,構成完整的建築物資訊模型。因此在建築技術規則 建築設計施工編第一、二章的基礎法規分析結果多數集中在分類1 與分類 2,屬於可以檢測範圍。但進入建築技術規則建築設計施工編第三、第四 章的法規檢討,在實務操作上,需要借助外部GIS 圖資整合或專業驗證法 規的協助,無法直接由單一模型資料檢測系統完成,且各縣市的圖資數值 化程度不同,都會造成各縣市電腦輔助檢測發展項目與深度的差異。建議 可以從法規檢討實務上,重新檢討 BIM 模型的資料輔助程度並與人工審 查的搭配。這部分需要配合地方政府建管單位的 BIM 發展計畫,並與中 央主管建築機關討論出一致性的檢討標準,才有可能繼續深化分類3 與分 類4 的法規檢測。 建議四 中長期之建議:因應BIM 應用制定建築管理的新模式-符合 BIM 應用的出

(16)

圖與圖說審查方法 主辦機關:內政部建築研究所、內政部營建署 協辦機關:臺北市政府都市發展局、桃園市政府建築管理處、中華民國全 國建築師公會、臺北市建築師公會、新北市建築師公會、桃園市建築師公 會、台灣建築資訊模型協會、中華民國公共工程資訊學會 本研究案中有針對應用 BIM 進行建築設計時,在建築管理上可能帶 來的改變,建築資訊建模最重要的目的就是流暢的跨專業與跨階段資訊整 合。資訊整合的關鍵是資料內容與格式的共同標準。目前台灣建築產業各 階段之建模標準往往參考蒐集來的契約範本以及國外各階段 LOD 的規 格,而制定範本與各階段LOD 規格標準的過程中未必能夠真正考量本土 產業執行面上的需求,而導致在執行上種種浪費與窒礙難行的狀況。因應 BIM 應用發展的快速,建築管理制度上也應該跟上 BIM 發展的腳步,提 出一套符合 BIM 應用的出圖內容,符合資訊化應用也符合建築管理審查 所需的相關資訊,制定出一個符合現代資訊化建築送審的前瞻作法。 建議邀集具備能夠執行並整合建築基本設計階段的專業人士透過研 究計畫進行整合,計畫成果能夠提出基本設計階段的建築資訊建模出圖標 準。 建議五 中長期之建議:法規標準化架構BIM 與 GIS 整合應用 - 建築設計統計分 析儀錶板與建築資料庫 主辦機關:內政部營建署 協辦機關:內政部建築研究所、中華民國公共工程資訊學會 建議依據本次研究所提出之法規標準化架構作為基礎,透過設計階段 導入符合法規樣版設所建置的模型,進行可量化的統計分析應用,其中包 含了建築資訊中的幾何與非幾何資訊,例如綠化面積、開放空間面積、消

(17)

XIII 防相關配置與空間大小、不同用途的空間數量(住宅之頪的)、停車位等, 並結合GIS 地理資訊,透過標準化資料進行數據收集,以城市治理的角度 進行大數據分析應用,例如區域中住宅或商業的容積樓地板開發比例、開 放空間戶綠化空建在城市區域的比例等,針對城市規劃與治理的角度結合 建築資訊是未來值得深入研究及發展的課題。

(18)
(19)

XV

ABSTRACT

Key words :Automatic rule checking, Building codes, Building Information modeling, Industrial Foundation Classes, Model View Definition

IFC representation of Building technological codes

- Part of Building design and construction act, Chapter 1and Chapter 2. Automatic rule checking has been used in many applications of BIM development. The building permit can be a milestone for technological advent of building code checking. Agent of Taipei City government initiated the effort in 2009 with a project to study the feasibility of BIM supported administration for building permit. In 2014, with the joined effort from New Taipei City government, the first version of code-checking system was implemented and incorporated into the administrative process of building permit. From 2014 to 2016, the two governments successfully used the system for more than twenty-six construction projects of public work buildings, including residential buildings, sport centers, hospitals and office buildings.

Facilitated with the skill and experience of code checking system development for both city governments, this project extended the contribution by defining the structure of required model view for the indispensable building code checking information within the IFC format. The research scope includes chapter 1 and 2 of building design and construction parts for architecture technological codes. Collaboration with architects on building permit code checking was carried out as action research for the project.

The contribution includes definitions of essential building elements and their interrelationships for constructing the foundation of model view definition. Working template would also be used for assisting architects on building code checking for improving the quality and efficiency of the design process.

This project consists of an action research by providing working template for the design team of a professional architect’s office. The template was used and tested in actual projects. Through the experience gained in the practice, the template

(20)

and the information modeling standard defined in this project was refined. This research complies with the IFC format and structure, incorporated with experience in the implementation of computer programs for code-checking.

The research in C. Eastman (2009) provides an overview for BIM-assisted code-checking, which was used to establish the basis by Taipei city government for the feasibility study in 2009. In 2015, Solihin & Eastman proposed 4 categories of rule-checking to distinguish levels of complexity and difficulty.

This research established the basic structure for the information exchange standard for code-check in Taiwan. The contribution would facilitate future development for code-checking systems in Taiwan.

Five suggestions for the development of code-checking are made, within which two of them are for short term plan and there are for long term development.

1. Continuous development on the data exchange standard for the Design and Construction parts of Building code checking handbook. Based on the result of this research, further development should be focused on the standardization of terminology and standardization on rule-check logics. 2. Integration of concerning parameters to the working template with more

generic code-checking standards for domestic uses. This research has integrated standards for Taipei city and New Taipei city. Further development can be extended to broader ranges.

3. For long-term developments: Establish human-machine integrated systems for assisting building code-checking. Based on the research finding of this project, current IFC2X3 structure, using IfcObjects and IfcSpace to encode building model information, and using IfcRelContainedInSpatialStructure to link IfcObjects and Ifcspace to construct a complete information model is feasible. Most codes in the first and section chapter of the Building Design and Construction parts for Building code handbook are belonging to the first and second levels of complexity, which are more feasible. The third and fourth chapters may not be of the same situation for many of the codes require external information from outside of the building information model, such as the geological information system of the cities.

(21)

XVII

4. Long-term suggestions: The model pre-checking methods for the submitted IFC file. It is required that a convenient system for pre-checking of the submitted file to make sure the submitted file complies with the required standard on the format and content of the submittion.

5. Long-term suggestions: The integration of BIM-based code-checking system with the Geological Information System of Cities and the establishment of the building information database for statistic and big-data analysis. The code-checking system will serve as a channel to bring huge amount of building information of the city. It is important that such information can be organized into an usable database to provide data for statistical and big-data analysis. The result would enable the development of information dash-board for the city administration as decision supports.

(22)
(23)

第一章 緒論

第一節 研究緣起

一、 研究主題 本計畫進行的研究主題臚列如下: (一)調查目前建管機關實際應用 BIM 輔助建築許可檢測應用情形,整理分 析技術規則檢測樣態。 (二)分析建築設計施工編第 1、2 章,整理可應用 BIM 技術完整檢測、部 分檢測與無法檢測之法規樣態及邏輯化分析結果。 (三)依據前項分析範圍與結果及條文內容,參照 IFC 資料架構研訂檢測所 需基本物件的定義、資料屬性、以及物件之間的類別、從屬、關聯性 等(如尺寸、建築類別、區劃屬性等)。 (四)透過實際案例與建築師或建管機關合作就研究所擬訂法規檢測用元件 之資料屬性、關聯架構等進行檢視調整。 二、 研究緣起 近年臺北市、新北市及臺中市均持續嘗試應用 BIM 輔助建築管理行政作 業。臺北市政府都市發展局與建築管理工程處整合各項建築開發許可申請作業 系統以及都市計畫基礎圖資於雲端無紙化作業平台 Taipei Paperless Cloud Service System (TPCSS),積極打造無紙化環境,並作為受理 BIM 模型審查的 基礎。新北市政府工務局負責發展 BIM 建築執照審查樣版檔,協助建築師提 送內含法規資料的建築許可模型。鑑於目前是以臺北市、新北市地方政府導入 BIM 應用發展,且係依個別建管相關條文進行檢測程式開發,為協助中央與地 方建管主管機關加速應用 BIM 輔助建管行政作業,本案擬以全國一體適用角 度並以通用性的建築技術規則基本定義與一般設計通則為研究對象。參考直轄 市相關電子化申請系統與法規檢測開發經驗,再參酌國際間應用 BIM 常見的 IFC 建築資訊交換格式來記載檢測資訊,作為申請建築許可過程中資訊交換的

(24)

標準。藉以降低各地方政府主管建築機關導入法規檢測的技術門檻與成本。從 建築設計施工編第1 章用語定義與第 2 章一般設計通則開始,分階段分析通用 性的建築技術規則檢測資訊需求內容與IFC 元件(Element)歸類,逐漸建立統一 的建築許可BIM 模型交付標準,作為建築技術規則其它篇章檢測開發的基礎。 三、 預期目標 (一)提出國內建管機關實際應用 BIM 輔助建築許可檢測應用情形,整理分 析建築技術規則檢測樣態調查結果,讓各界對法規檢測有充分的瞭 解。 (二)提出建築設計施工編第 1、2 章可應用 BIM 技術進行檢測分類表。 (三)建立以 IFC 資料架構為基礎之法規檢測所需基本物件(Object)的定義、 關聯架構等,作為各項軟體開發之參考。同時可嵌入元件中以充實內 含資訊豐富度及可用性。可發展成為全國性建築執照法規檢測 MVD 資訊交換基礎或建立法規檢測樣版檔。提升設計品質與效率,亦可提 升建管作業效率與正確度。 (四)提出審查圖說內容與模型上繳檔案格式標準之建議方案。分階段建立 具通用性的建築技術規則檢測資訊需求內容,使業界有統一的建築許 可模型交付標準,並提供中央建築主管機關推動相關電子化作業之參 考。

(25)

第二節 研究背景

一、 研究背景說明

美國國家建築資訊模型標準專案委員會(US National Building Information Model Standard Project Committee)對建築資訊建模有以下的闡述[1]:

“Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition.” 從基本定義,如何提供一個可行的環境來建置建築物生命週期中各階段決 策所需之共享性知識資源,是實踐 BIM 一個相當關鍵性的議題。這個共享性 知識資源的基礎架構可能至少須具備幾個特性: 1. 具有不斷成長與新陳代謝特質的有機體。 2. 具有延展性、續接性,雖可斷開獨立運作,但隨時可合理銜接整合。 3. 資訊發展層級,包括幾何與非幾何,得視作業需要程度做深化或簡化。 4. 配合電腦軟硬體及網路頻寬之能力,充分應用資訊技術對資訊儲存與呈 現做最佳化的規劃。 以英國政府營建策略的推動,從 Level 0 逐步要求,2016 年要求的 BIM Levle 2 成熟度仍以檔案為基,部分自動化的程度,而真正更全面自動化的 BIM Levle 3 成熟度是預期到 2025 年達成,這也是考慮到普遍業界的接受度,以及 對資訊技術應用的保守規劃,這是相當值得我國借鏡的策略。也許,目前BIM 的相關資訊技術與軟體工具的使用仍存在侷限性,但善用既有的熟悉的工具與 技術,若能充分熟習它,充分運用它,實際上是可大幅改善傳統工程上的一些 易犯的缺失。BIM 的推行絕對不可忽視業界從根深蒂固之傳統作業模式,推動 過程要兼顧逐步轉移與接受的進程。

(26)

二、 研究目的 建築法規導入 BIM 不能只是由地方政府努力,如何進一步將建管法規進 行規格化標準更是首要努力目標,透過地方政府所累積的經驗,由本案研究重 新檢討建築法規如何規格化、邏輯化並結合國際標準(IFC)架構與地方政府所努 力的成果(包含法規樣版、法規參數化與檢測邏輯分析),相信訂定出全國一致 性的標準規範。 本團隊自2009 年起投入應用 BIM 輔助建築管理行政作業可行性之分析, 於2014 年開發出第一版的系統之後,至 2016 年已經在臺北市及新北市超過 26 項公共建築成功地進行實際的應用。本計畫的目的為基於為臺北市、新北市政 府所累積的技術及經驗,將建築技術規則建築設計施工編第 1、2 章的法規所 牽涉到的審查資訊進行分析。藉由MVD 的模型資料架構概念,將建築執照所 需的法規檢討資訊,以模型視圖及明細表的編定的方式,將建築技術規則基本 名詞定義與屬性資訊集合成一個可實際操作的樣版。這個樣版成為各項法規檢 討程式發展的基礎,當然亦可作為後續第 3 章與第 4 章防火避難設計檢討所需 之應用程式開發基礎資料架構。 三、 本研究計畫之重要性 目前,國內各地方政府針對建管法令自行研究,重點著重在各地方政府經 管業務所涉及的相關建管法令及事項,雖有部分重點與中央統一法令相關,但 仍屬於各自發展,本案針對全國統一的建管法令進行規格邏輯化之通盤檢討, 並進一步針對 BIM 應用通用交換格式 IFC 所規範出資訊規格,這樣有利於建 管法規條文數位化,並且將建管法規於 BIM 資訊建模中的資訊應用規範明確 規格化,進一步讓各地方政府有統一標準可以依循,本案不是只有標準的制 定,更利用實際案例與現行國內外執行之專案進行通盤討論,符合實務可行之 規範。 本案從建築技術規則建築設計施工編第1 章用語定義與第 2 章一般設計通 則開始,期待為建築技術規則法規項目邏輯化及數位化奠定分析的基礎,在此 基礎上進行後續發展,利用BIM 建築資訊應用於數位城市的建築管理上。

(27)
(28)

第三節 研究方法

一、 研究採用之方法 本研究計畫分兩大方向,一是以行動研究法,以實際案例參與整個研究, 從法規的分析邏輯化、IFC 的資料架構解析、樣版的探討、實際案例的演練等 過程利用實際案例驗證並實作確認研究成果,本會從101 年起研究法規與 IFC 交換格式進行雙北電腦輔助建照審查系統的建置,所以法規分析可以與雙北電 腦輔助審查系統所進行比較分析或整合應用,透過雙北系統的實作成果,進一 步針對本案的法規研究分析與IFC 架構的一致性與可行性進行比較分析;另一 是針對國外相關文獻及研究現況進行彙集探討,可以與本案主題進行比較及探 討。在過程中會依其需求,邀請建築師事務所及相關的專家學者給予意見或補 強研究方向與內容。 在整個時間規畫上會分成兩個重要階段,期中報告前有兩項重點:第一是 針對國內臺北市、新北市政府針對建造執照法規審查之應用與分析案例進行研 究,並參考國內外相關IFC 架構與 MVD 分析之相關文獻進行探討;第二是會 完成初步的架構分析及標準制定雛型,並且擬定出案例參與測試與實作的策 略;期末報告前重點會放在實際案例的驗證與測試,並透過實際案例的實作進 行相關分析結果與標準的修正,讓此研究分析之結果與實際操作可以結合,同 時也在各階段邀請專家學者一同參與討論並給予意見,讓研究成果可以落實實 務應用。 以下分別針對研究重點進行簡述: 1. 法規的可運算邏輯分析 a. 法規解析透過參數化設定判斷 分析法規運算邏輯與所需參數化之內容,將法規所需參數設定於各 類別(窗、門、牆、房間、面積、自訂元件等…)或利用其他制定方式, 應用IFC 進行資料存取,配合法規參數進行法規邏輯化函式可行性判斷。 b. 法規解析可結合模型屬性資訊與自定參數判斷

(29)

分析法規運算邏輯可於各類別(窗、門、牆、房間、面積、自訂元件 等…)項目中直接應用的屬性資訊或模型可直接使用之設定資訊,結合所 需參數使用判斷,應用IFC 進行資料存取,配合法規參數進行法規邏輯 化函式可行性判斷。 c. BIM 模型繪製與法規解析應用之可行性 可運算邏輯分析之法規檢測項目若是針對模型本身物件與物件之 間的關係才可進法規邏輯化分析檢討,或法規檢討內容相對於模型中是 針對一個虛空間的檢討,此類就須直接針對模型進行檢測,模型轉出IFC 後,透過程式撰寫進行相關檢測運算的可行性。 2. IFC Schema 與 MVD 資料編訂 IFC 的基本架構包含四個階層,這四個階層定義 IFC 資料的分類位 階。依序為最底層的基礎資料描述(Resource  Layer)、核心層(Core  Layer) 外部資料註記、整合層(Interoperability Layer)提供 IFC 與外部軟體之間交 換的能力、領域層(Domain Layer)提供各專案最基本命名分類。法規檢測 主要為將外部之法規資訊加入模型資料當中,因此在核心層(Core Layer) 編定許多資訊,以產品資料綱要(schema)定義建築物元件組成,IFC 的 schema 有很清楚的上位類型  (super  type)與下位次類型(sub  type)  的繼 承關係。於此定義所有屬性資料的位階,MVD 的資料編定之前,必須先 釐清這些位階,才可以讓法規資訊與模型元件結合(詳述於第 3.1 節)。  各領域專業資訊需求(requirement)的彙整與交換是 IDM 層級工作事 項。進入模型視圖 Model View Definition (MVD)的層次,必需將這些工作 項目標準化,以便能順利進行專案模型建置(BIM model preparation)。以 建築執照法規審查為例,不同圖說是要交代不同的資訊項目。例如綠化 面積涉及地面層景觀高程設計檢討有關,因此規定在 GL 平面圖繪製。 建築面積涉及各樓層樓地板投影在地面層面積檢討,因此要求繪製在地 上一樓平面圖。其他如防火區劃面積因分屬各樓層檢討,則繪製在各個 樓層平面圖。其他如各樓層之空間名稱標示、免計容積樓地板面積標示

(30)

等,皆屬於個別之空間檢討,也必須提供標準的樣版才有辦法讓檢測程 式擷取到必要空間資訊。而實體物件(柱、梁、板、牆門、窗等)之屬性 項目,在現有 BIM 軟體工具是較清楚的,故以增列法規檢討基準值為 主,不另定義視圖。IFC 與 MVD 之間的 IFC Schema 架構關係如下圖 1-1 所示: 圖1-1 IFC Schema 應用與 MVD 編定架構 (由本研究繪製) 從圖 1-2 NBIMS 在描述模型法規資訊整合交換的發展與使用的流 程,在藍色區塊包含設計(design)與結構(construction)兩個重要的工作項 目 。1. 建 立 標 準 設 計 (standard design) 的 資 料 交 換 格 式 。 當 中 有 (1)Exchange requirement model(交換模型),如前段所述的建築面積、防 火區劃就屬於資料交換需求模型,在此視圖下會,針對特定的法規檢討 項目,訂定特別的資訊標註項目;(2)Generic Model view definition(通用 模型視圖)適用規範對通案性的法規檢討資訊,例如在各層建地平面圖標 註 各 空 間 名 稱 的 法 規 屬 性 。2. 結 構 (construction) 是 指 在 軟 體 執 行 (Implementation software)環境下的資料架構協定。當中包含(1)模型視圖

(31)

的 定 義 與 執 行 規 範 (Model View Definition and Implementation Specification ),非常清楚的模型資料與 IFC 資料關係連結(2)軟體產品執 行 的 便 利 性 與 驗 證(Facilitate SW product ; Implementation and Certification),這裡指的是由特定機構(例如 NBIMS)對於由進行軟體內 部資訊的編定與交換完整性,進行技術評估與測試,進而確保BIM 的模 型資訊可以被完整交換。軟體內部資訊指的就是IFC 屬性分類的完整性。 有關IFC 屬性分類的完整性,從建築計畫擬定的內容來說明,建築 物的構成可以分成實體的構件(建築物結構體)與空間元素(部位名稱)。在 IFC 的資料架構也是依循這樣的分類架構。從建築模型轉出的各部位構 件 IFC 資 料 結 構 (schema) 中 , 它 的 第 一 層 可 以 看 到 最 基 本 的 分 類 IFCObject 與 IFCElement 。實體的構件(柱、梁、門、窗)會歸屬在 IFCObject,它是單獨存在的構件。空間元素(辦公室、電梯、樓梯或機 電設備間等建築計畫之空間名稱)則會歸屬於 IFCElement。在 IFCElement 會有比較複雜的組合(Composite)與拆解(decomposed)關係的描述,它在 律定所有建築物空間彼此之間的協同關係(IFCRelAggregates)。而構件與 元素最終的組織(hierarchy)關係則以 IFCRelContainedInSpatialStructure 進行整合。 綜上,可知MVD 是如何將專業資訊導入模型的重要介面,也是模 型準備最重要的基本工作,MVD 扮演專案設計的功能(模型作業環境設 計與檢測程式整合),它有四個面向要考量:(1)視圖定義;(2)明細表應 用;(3)軟體既有物件屬性與參數值(4)專案參數與座標律定。因此,MVD 也會隨著軟體操作環境的不同(比如:Revit 與 ArchiCAD)而調整。考量的 是軟體執行驗證(Software implementation and certification),也就是 IFC 資料匯出的完整度。

(32)

圖1-2 模型法規資訊整合交換的發展與使用

(33)

3. 臺北市、新北市政府的系統在地化研究 近年國內針對建築技術規則相關法規分析以臺北市、新北市政府最 為積極,也應用系統之實作開發出可檢測之系統與法規樣版,可以借鏡 臺北市、新北市政府之成果,與本研究案結合,從理論分析到實務應用 可以串聯結合,從地方到中央整合出一套完整的法規邏輯化架構,而這 樣的邏輯化架構都是基於IFC 資料架構的原則。 4. 業界建築師的案例實作 除了上述所提的分析與研究,目前已有業界建築師事務所以新北市 的法規檢測樣版,做為事務所內部客製化樣版的基礎,再結合業界軟體 公司發展屬於自己事務所需要的應用程式(API),這樣的模式是最佳的 具體應用的實證。期待本計畫完成後,可以又更多的建築師以實際案例 進行應用,讓法規邏輯化於業界中不同角色都可以理解並且實際應用。 二、 研究採用方法之原因 探討 BIM 應用於建築管理,其中建築法規的探討與數位化是一個很重要 的關鍵與門檻,透過IFC 通用交換格式的架構,提出一個彈性且通用的分析方 法,是讓建築法規審查邁入電腦化應用的重要基礎,除了法規分析邏輯化的關 鍵基礎之外,必須結合建築設計專業、建築法規專業及資訊分析等不同專業的 參與,將數位化的法規實作於 BIM 資訊建模的應用中,並進一步與資訊專業 進行程式規格制訂與架構分析,才可真正的落實於實務應用上。以上擬訂之研 究方法,正是以這樣的理念所構成,由於考慮層面寬廣、技術挑戰性很高,必 須步步為營,才可望交出亮麗成績。 三、 預計可能遭遇之困難及解決途徑 本案聚焦在「建築設計施工編第1、2 章」,雖已將範圍縮小,但建築法規 之制定原則並非以發展數位邏輯化的概念出發,部分法規資訊並不完整,資訊 無法全部由IFC 模型資訊中取得,而法規文字的解讀更可能因專業者自身實務 經驗的累積而出現差異,在程式編定可量化分析原則下,如何將原始法規條文 轉換成數位化可判讀邏輯是最大挑戰與困難。同時將此邏輯解析於IFC 通用交

(34)
(35)
(36)

第二章 國內外相關文獻探討

目前以 IFC 格式作為建築資訊模型的規則審查系統的軟體平台有 Solibri Model Checker、Jotne EDModelChecker、FORNAX、SMARTcodes,各國政府 所發展的法規審查系統是以上述的平台為基礎發展。Eastman(2009)分析法規自 動審查系統必定包含四個階段的程序,規則解釋(Rule interpretation)、準備建築 模型(Building model preparation)、規則執行(Rule execution)、規則報告(Rule reporting)。 法規解釋作為發展自動審查系統的第一步,目前並沒有一個健全的標準來 定義建築語意和資料交換需求,仍是以人工手動的方式處理從 IDM 到 MVD 的資訊轉換,容易產生對一個資訊單元有多個解釋的衝突狀況。Lee(2012)開發 一空間資料庫(Space database)用來支持自動化建築設計審查系統,以空間物件 (IFCSpace)攜帶豐富的空間物件與空間使用的語義,這些空間物件可以根據空 間資料庫自動的組織與分類到 BIM 系統中。這個對應的過程需要統一名稱(關 鍵字)作為檢索的依據,提高辨識率。該空間語義對於自動化評估建築模型是 重要的因素。為了完整的建立建築法規中的語意(semantic)和邏輯的一致性 (logical consistency),Pauwels 認為應該要建構語義規則檢查的環境,將法規條 文的內容模組化以增加使用的靈活性,讓程式能延伸與推論額外資訊,採用資 源描述架構(Resource Description Framework, RDF)作為表達方法,描述語義網 路(semantic Web)的建構與關係(Pauwels et al., 2011)。

Solihin(2015)根據其計算複雜度將自動化的 BIM 法規檢測系統分成四類, 並舉例說明與測試。如圖2-1 所示,這四個類型是一個由簡單到複雜運算漸進 的過程。依序概略說明如下: (1)第一類規則是針對模型本體的資料進行型明確資料的查核,用來檢查 BIM 模型內部之實體元件資料與屬性資料集(dataset)是否正確、完整。如:防 火牆、門、窗等類型,必須具備應有的防火屬性資料。 (2)第二類規則是針對內部屬性資料的延伸應用。主要針對一般性的函數

(37)

或計算公式進行運算,例如:門窗數量計算、相同類組空間的面積計算、兩扇 門元件之間的距離檢測、門扇的法規要求寬度與開門的方向等。 (3)第三類規則系統是需要應用外部資料結構,同時需要進行法規檢討規 則的語義條件分析。例如樓梯淨高、停車場淨高檢討等幾何檢討類型的法規。 它需要分析物件與空間之間幾何碰撞關係。國外案例有新加坡 FORNAX™針對安 全梯的逃生方向檢討,亦屬於此類類型。第三類的法規類型對於法規檢測的幫 助效益最大,因為建築物的空間關係不明確與淨距離檢討不足,會涉及建築物 結構體的實際施工行為,容易造成工地現場施工錯誤。 (4)第四類規則系統是需要”專案解決能力證明(proof of solution)”,除了幾 何關係的檢討外,它還需要引入外部的專案資訊或知識。例如綠建築專章檢 討、開放空間獎勵面積檢討、低衝擊開發保水設計評估(LID)與建築物防火性 能評估驗證等,均屬於第四類的法規檢討類型。因此,第四類法規比較貼近於 專案的評估系統,而非單指某一項法規標準檢討。這在目前的法規檢測範疇應 用較少,也是未來值得繼續研究的領域。 圖2-1 四種類型的法規檢查演進架構圖 (圖片來源:Solihin & Eastman, 2015)

Eastman(Y.-C. Lee, Eastman, & Solihin, 2016)提出以"知識本體論"為基 礎,將各專業領域知識形式化(formalizing domain knowledge)"應用"精確定義 的資料模組"概念,整合出一個NUnit2.0Unit 平台架構,以驗證個別物件資料 與模型視域(Model Views)之間資訊傳遞的一致性。它利用語意推理的方法,討 論構件實體之間的聚合關係(aggregate relationship),讓軟體開發商與專業領域 者可以明確的定義MVD 的對應需求。在這篇文章中,使用 IFC server ActiveX component(簡稱 IFCsvr) 驗證案例 P21 的混凝土構件內的實體(entities)、屬性

(38)

(attributes)、性質(properties)與文件之間 MVD 的關係。IFCsvr 涵蓋所有的 IFCschema、參數、屬性與元件關聯性等。從圖 2-2 中有三個項目值得注意, IFCsvrlibiaries 是構件的參考資料,允許使用者在元件資料庫中輸入相關法規需 求的條件,以找出符合之構件元件、IFCsvrdesign 是元件設計資料表,所有 IFC 物件的基礎資料會編定在這個物件,而IFCsvr.Entity&Attribute Builder 則是實 體物件底層的資訊,做為IFCsvrdesign 物件編定的基礎。由 IFCsvrdesign 所帶 出的物件資訊會在 NUnit2.0Unit 這個平台架構進行資料驗證,用來確認 IFCsvrdesign 所帶出的資料模組 MVD 所規範的資訊需求是一致且符合規定的。

圖2-2 使用 IFC server ActiveX component 驗證預製混凝土的 MVD 架構 (圖片來源: Y.-C. Lee, Eastman, Solihin, & See, 2016)

第一節 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 交付格式已經逐漸成

(39)

為 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)定義建築物元件組成,像是空間、基地、建築物、建築元件與資 料標註等。以建築設計而言,從建築計畫擬定的層次,對於建築的內外空 間構成與組織關係加以界定,再輔以另外兩綱要架構,定義建築設計工作

(40)

流程與管控,像是個階段應完成之任務、程序、工作流程與建築許可等。 若以法規檢測角度,所以基本名詞背後構成的要素,或法規檢測所必要被 萃取的模型資訊,都要在這階層被明確敘述,也就是模型樣版編定的資料 架構都屬於核心層的事項。因此 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 為基礎進行資訊交換也降低溝通成本。

(41)

圖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)

(42)

分析出來第一、二章的通案法規檢討項目,如門(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 兩個元件繼承屬性的關係。讓建築物的實體 元 件 與 空 間 元 件 可 以 被 整 合 。 可 以 看 出 一 部 樓 梯 , 透 過

(43)

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 進行物件的關聯性編定,達到空間模型 多樣化的產製與提高物件快速查詢的效能。 

(44)

 

圖2-5 樓梯約束空間與結構體的關係 (圖片來源:BuildingSMART IFC2x3 TC1)

(45)

二、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 的標準制定範例,這樣的標準制定可望提供一個針對 法規邏輯化規格化的一個重要方向。

(46)

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

第二節 國內外有關本案之研究情況

國際標準組織(ISO International Standard Organization)所制定的 STEP (Standard for Exchange of Product model data)以及 IAI 組織(International Alliance for Interoperability)所制定的 IFC 分別為工業界及營建產業制定了一 套產品資料交換標準。IFC 以層級的架構規範每一筆物件資料的上位繼承關 係,每一物件(Object)被視為一個實體(Entity),以物件導向的資料架構進行 元件資訊的標準化。世界有名的繪圖軟體公司(AutoCad、Bentley、Graphisoft) 皆已積極開發結合IFC 模型標準之繪圖軟體,BIM 的資訊應用將會更趨於標準 化。因此,在法規檢測基礎資料的發展上,只要釐清 IFC 的繼承關係,並清楚 知道模型資料的法規資訊,經過 IFC 資料匯出後,會被歸類到 IFC 屬性資料的 哪一個項目,這樣的檢測系統就沒有被軟體廠商與操作版本限制的問題。

法規檢測的模型資料(Model  data)與法規資訊(rule  information)要能夠被檢 測系統的判讀或界定(definition),必須經過一個嚴謹的資料整合交付的過程。 當中包含 IFC、IFD( International  Framework  for  Dictionaries 國際字詞編訂架構 與)、IDM (Iformation Delivery Manual,資料傳遞綱要)三個工作項目的整合。簡 言之,IFD 是一個資料字典(data  dictionary)的概念,提供名詞基本的屬性資料

(47)

與法規語詞分析(semantic)。本研究針對建築技術規則設計施工編第一、二章的 名詞定義(名(主)詞/動詞/謂語;如實體物件:門、窗樓、梯;空間元素類:居室、 陽台、梯廳等)、法規繼承關係,進而萃取的標準化資訊;IDM 提供資料交換機 制(process),也就是將設計階段建照審查與施工階段之現場勘驗模型應交付的 資訊內容,回饋到模型資料。藉由 MVD 的視圖編定讓操作者在建模過程中, 被引導逐步輸入正確資訊;IFC 提供一個很好的資訊分類與資料交換格式操作 者並不需知道太多 IFC 的知識,只要匯出正確版本(IFC2x3)即可,資料運算與正 確性的驗證是檢測系統的工作,這就是法規檢測系統運作最基本的邏輯概念。 IFC、IFD、IDM 這個三角關係如圖 2‐7 所示。  圖2-7 IFC、IFC 與 IDM 資料架構圖 回顧自動化法規審查系統的發展的歷史,新加坡政府自 1995 年開始有對 於2D 圖紙的條碼檢查,1998 年開始以 IFC 格式作為建築資訊模型的基礎。從 2003 年世界銀行開始對全球經商法制環境進行評比,新加坡政府遂行進入第二 階段的 BIM 建築資訊模型與法規檢測整合之應用研究,2008 年推動企業開辦、 申請建築執照的 CORENET rule-checking system,近幾年來獲得相當高的評 比,展現都市的活力與競爭力。配合制訂相關法規及推動政策,導入新知、新 制及新的資訊技術以強化推動力及執行力,值得借鏡。

除此之外挪威、澳洲、美國政府也積極發展符合該國法規的審查系統,這 些系統仍然在不斷測試與開發的階段,已經完成的自動化審查也僅限於部分項 目,例如火災逃生路線的檢討、輔助特定族群、施工安全規範(Zhang, Teizer, Lee, Eastman, & Venugopal, 2013)。目前以 IFC 格式作為建築資訊模型的規則審查系 統的軟體平台有Solibri Model Checker、Jotne EDModelChecker、FORNAX、 SMARTcodes,各國政府所發展的法規審查系統是以上述的平台為基礎發展。 C.Eastman(2009)分析法規自動審查系統可包含四個階段的程序(如圖 2-8 所 示),規則解釋(Rule interpretation)、建築模型準備 (Building model preparation)、

(48)

規則執行(Rule execution)、規則檢測報告(Rule reporting)。這四個階段的程序說 明了從法規演譯到最終檢測結果呈現的過程,但與其說是檢測,倒不如說它是 一個設計自我評估的輔助系統,每一個階段所象徵的意義說明如下: 規則解釋(Rule interpretation)作為發展自動審查系統的第一步,它需要一個 健全的標準來定義建築語意和資料交換需求。完整的建立語意(semantic)和邏輯 的一致性(logical consistency)是最重要的前置分析工作,由於是從人的邏輯轉 譯到電腦的邏輯,因此各類名詞的屬性架構描述與參數檢討標準界定就非常重 要,Eastman(Lee, Eastman, & Solihin, 2016)提出以" ontology-based(知識本體 論) " 為 基 礎 , 討 論 如 何 將 各 專 業 領 域 知 識 形 式 化 " formalizing domain knowledge",並將模型資料在 MVD 編定成資料模組。讓軟體開發商與專業領 域者可以明確的定義MVD 架構下的對應需求。

圖2-8 法規檢測的基礎流程架構

(資料來源:C.Eastman,2009/06/30,Automatic rule-based checking of building designs,摘 自內政部建築研究所102 年「BIM 導入建築管理行政作業法規調查研究」案之重新繪

製圖)

建築模型準備 (Building model preparation)是建築師事務所操作端的 工作,這些工作包含(1)模型視圖的產製提供(a)取得特定物件的完整參數(b) 獲得新的模型(C)呈現基本模型視圖與分析。(2)清楚的列出法規參數。因此,

(49)

建模者依照法規樣版的資料欄位輸入相關數值或依照樣版明細表定義的名詞 進行空間標註。經檢測系統從模型視圖取得資料以供查核。 法規執行(Rule execution)與建築許可行政審查需求項目息息相關。行政 部門必須先分析法規檢討的資訊需求再反映到的法規檢核系統項目的開發。法 規執行所需要的資訊內容,需要建築師的模型資料。因此,法規執行與建築師 所繳付模型完整度相關,在第一關的基礎環境檢測就必須驗證,它包含兩個項 目:(1)模型視圖的語法架構檢測。(2)視圖上繳的管理(a)法規完整性查核(b) 模型版本的一致性。只要基礎專案資料參數設定有誤,系統就會退回上繳的模 型資料,它的概念就好像建築執照在掛件申請的第一關就須進入書圖完整度審 查。 規則檢測報告(Rule reporting)檢測結果是為提供行政部門與建築師可以 快速有效溝通。系統會將檢測結果通知繳件人與行政部門。以新北市的電腦輔 助檢測系統為例,規則檢測報告可分為兩個階段,第一階段為電腦完整檢測通 過的結果,它包含兩個項目:(1)法規幾何案例呈現(2)數值運算與檢測法規之 比對結果。第二階段為審查人員最終確認的結果,如此的機制是反映出檢測系 統只是個輔助的角色,還是需要人員做最終確認。 從國內目前臺北市、新北市政府的發展成果來看,其技術應用的深度與成 熟度並不亞於新加坡政府的 CORENET rule-checking system。2016 年 3 月 14 日 BIM 教父 C.Eastman 更親自造訪新北市政府工務局,盛讚臺灣的法規檢測 成果已屬世界先進領域。接下來的發展重點應該是推動讓全國一體適用的法規 檢測版本,非僅限於一的地方政府機關。對於 IFC 的資料應用,他也建議應該 將此成果介紹給國際相關法規檢測研究領域認識,同時藉由法規檢測改變建築 師對於模型資料繳付內容的深度認知。政府部門建立可以被深入分析、應用大 數據的資料平台。這才是推動法規檢測導入數位建築資料(digital building data)應深入思考的範疇。

(50)

第三章 應用 IFC 記載建築法規資訊

第一節 法規資訊結合 IFC 格式

一、建築法規資訊的分析流程 法規分析程序須將在地化的建築許可相關規定(包含:項目具體要求、設 計指南、建築法規、等…)中建築法規部分已 IFC 架構的內容進行分析,本案 中針對建築技術規則-建築設計施工編第 1、2 章進行分析標的,並從中找出法 規邏輯化規則的機制,並將可執行的法規作出明確的定義,成為可邏輯化法規 的標準,可邏輯化分析的法規也可以說就是前面章節中所提到的 MVD,這樣 的標準內容將是發展檢測系統的一個重要依據,同時依據這樣的標準將可以規 範出為了提供檢測系統所能閱讀的相關資料內容與檔案格式(IFC)。 IFC 格式是目前國際上針對建築資訊模型內容廣泛且普遍使用的格式,IFC 架構的法規分析將可符合各軟體間的共通標準,不受限於特殊軟體,法規標準 化的過程也提供了設計者與審查人員之間的一個共同標準,公開的共同標準將 不再讓法規出現因人而異的模糊解釋,所帶來的好處與優勢能為我國建築審查 作業帶來更好的發展。以下流程圖可以說明上述所提的分析程序。 圖3-1 法規邏輯化分析程序

(51)

以 IFC 架構來解析法規做法可以將法規所定義出的目標物件進行資訊架 構分析,找出屬於「元件/物件」或是「屬性/參數」將法規資訊進行明確定義, 在「元件/物件」中又可以進一步分析屬於面積/空間相關或建築物元件相關, 透過 IFC 架構格式將法規條文標準化,提供一個標準化的資訊規範。

圖3-2 以 IFC 呈現法規分析架構

(圖片來源:Translating building legislation into a computer-executable format) 在前一節有提到,IFC 架構除了定義建築物本體意外,也進一步定義了其 屬性資料,而屬性資料的分類,是結合模型繪製與建築資訊記載兩個重要層級 之組合應用概念,這將是提供邏輯化法規的屬性定義一個很重要的分類依據。

圖3-3 法規屬性分類 IFC 架構

(52)

二、法規運算邏輯分析之要素 以IFC 架構記載整棟建築物資訊的規格架構,將為我們帶來一個很重要的 法規邏輯化分析的依據,從建築設計與法規運算邏輯的兩個角度出發來檢視 IFC 的資料應用皆能符合其原則,這也進一步說明了,透過 IFC 架構所記載的 建築物資訊是可以進一步滿足法規運算邏輯的需求,所以法規運算邏輯分析在 這樣的前提基礎下有兩個關鍵要素。 (一)法規名稱標準化 將法規名稱標準化定義是以 IFC 的資訊架構實作建築法規的名詞內 容,以建築技術規則-設計施工篇第一、二章中所描述的法規名詞定義如 何與 IFC 架構作標準化之對應,例如:建築物中的空間名稱(ex:停車場) 及其構成物件(ex:停車位)、參數(ex:長度、寬度),同時以建築設計者的角 度去解析專案資訊模型中 IFC 格式架構的圖解,呈現法規名稱標準化的結 果如下。(完整架構請參考附錄三) 圖3-4 專案及建築基地相關物件圖解(範例) (由本研究繪製)

(53)

(二)運算方式/類型標準化 法規名稱的標準化分析,是法規邏輯化分析的重要基礎,但是只單純 將法規名稱定義標準化,並無法達到真正的法規邏輯化分析,法規邏輯化 分析的另一重要關鍵要素在於運算方式或類型的標準化,這兩大要素是相 輔相成的,又以運算邏輯至為關鍵,在法規分析的過程中,往往並非名稱 無法定義,而是定義出名稱後無法將法規文字所描述的內容以邏輯化運算 式來呈現。運算方式的標準化,大致上可定義出兩大類型。一是幾何運算: 布林運算(交集、聯集、差集)、最短距離、方向性、等…;二是數學運算: 加總、加減混合等。以實際例子來解釋法規邏輯化分析中如何將運算方式 標準化,而這就是未來針對法規邏輯化分析的重要方法。 a.範例一:停車場的停車位與進出口的門距離應有 75 公分寬以上 圖3-5 停車位與門之關聯圖示 (圖片來源:中華民國公共工程資訊學會) 可以再這條法規中定義出以下幾個重點: 1.樓層(有停車位) 2.門(IFCDoor) 3.停車位(IFCTransportElementType 或 IFCBuildingElementProxy) 4.最短距離(幾何運算) 必須先找出樓層資訊,透過有停車位的樓層,抓取出門與停車位兩個關鍵標準 化物件,透過定義標準化運算式:最短距離,可以知道此條法規的邏輯分析結果。

(54)

b.範例二:防火門尺寸高度≧180cm 且寬度≧75cm 圖3-6 防火門屬性參數關係圖示 (圖片來源:中華民國公共工程資訊學會) 可以再這條法規中定義出以下幾個重點: 1.門(IFCDoor) 2.高度、寬度(數學運算) 此條法規先找出建築物中的門物件,透過門物件中所定義出的屬性資料: 防火時效、防火等級,知道該物件為防火門,透過定義好的運算標準:高度、 寬度的尺寸,進行法規邏輯判斷。 從上述兩個例子中可以說明在法規標準化過程中,我們明確的定義了法規 名稱中有那些物件可以透過IFC 所取得,而這條法規的邏輯運算式屬於哪一個 標準項目,屬於幾何運算或數學運算,即可將本條法規實作成法規邏輯式,並

(55)

進一步提供給檢測系統做為系統開發的依據。 三、法規無法運算說明 法規運算邏輯分析勢必會遇到無法實作的情況,這些無法實做的原因大致 上可以分成兩類,一是目標物件無法明確定義,二是法規描述不明確以至於運 算標準無法定義,但這兩類是目前研究所統計歸納出的結果,未來還可能會有 更多不同的情況產生。以下針對這兩類問題舉例說明: (一)目標物件無法明確定義 在法規文字敘述中,看似已經明確說明的主要物件對象,將其放到建 置建築資訊模型的行為中,卻不是一個明確的物件,而法規運算邏輯分析 在定義法規名稱標準時,需要適時的考慮到實務建模的可行性,不應該定 義出過多不必要的物件,反而造成設計者的困擾並且脫離其輔助建築師設 計的真正目的與意涵。 a.範例一:第六十條,停車空間及其應留設供汽車進出用之車道:一、每 輛停車位為寬二點五公尺,長五點五公尺。但停車位角度在三十 度以下者,停車位長度為六公尺。大客車每輛停車位為寬四公尺, 長十二點四公尺。 圖3-7 車位與車道關係模型圖示 車道 角度

(56)

(圖片來源:中華民國公共工程資訊學會) 以上範例中所看到的「車道」是透過停車位擺放後所相對應構成的區 域,無法被明確的定義為某個物件\元件,或是賦予一個標準化的參數定 義,在範例的法規條文中,針對停車位角度進行計算的依據是相對應於車 道,所以對於車道該如何明確被定義,是這條法規無法運算的重要因素。 b.範例二:第六十一條,車道之寬度、坡度及曲線半徑應依下列規定:一、 車道之寬度:(一)單車道寬度應為三點五公尺以上。(二)雙車 道寬度應為五點五公尺以上。(三)停車位角度超過六十度者,其 停車位前方應留設深六公尺,寬五公尺以上之空間。 圖3-8 車道定義模型圖示 (圖片來源:中華民國公共工程資訊學會) 與前一範例一樣,進一步該如何定義「單車道」、「雙車道」,這也是 一個很有具代表性的一個案例,法規文字描述看似明確的數值與項目名稱, 但是以繪圖、建模角度思考時,卻難以明確定義清楚,這也是文字描述與 數位化之間所存在的差異性。 (二)運算標準無法明確定義 在法規文字敘述中,常常可以看到一句看是簡單的說明,卻可能因為 「設計」本身的特性有了無限可能的變化,在建築法規中這樣的例子會是 最常發生的,設計本身就有著無限可能的創造空間,造就出不同的設計想 像,而法規文字的描述該如何符合設計的可行性,或是應該在規定上定義 出一個基本條件即可,值得深入的思考。 車道?單車道? 車道?雙車道?

數據

圖 1-2  模型法規資訊整合交換的發展與使用

圖 1-2

模型法規資訊整合交換的發展與使用 p.32
圖 2-2  使用 IFC server ActiveX component 驗證預製混凝土的 MVD 架構  (圖片來源: Y.-C. Lee, Eastman, Solihin, & See, 2016)

圖 2-2

使用 IFC server ActiveX component 驗證預製混凝土的 MVD 架構 (圖片來源: Y.-C. Lee, Eastman, Solihin, & See, 2016) p.38
圖 2-3 IFC 系統架構表  (圖片來源:BuildingSMART IFC2x3 TC1)  以 IFC 格式產生的物件應包含以下特性。  1.幾何形體(Geometry)  所有實際存在且具有幾何性質描述的實體都屬於 Geometry 的範疇。 如柱體(IFCColumn)、牆體(IFCWall)、門(IFCDoor)等建築物構造體均屬之。  2.性質(Properties)  IFC 非常重視性質集(Pset_),用於定義共用的特定性能、材料類型、 環境性質等,在 IFC 的性質會歸納到 IFCP

圖 2-3

IFC 系統架構表 (圖片來源:BuildingSMART IFC2x3 TC1) 以 IFC 格式產生的物件應包含以下特性。 1.幾何形體(Geometry) 所有實際存在且具有幾何性質描述的實體都屬於 Geometry 的範疇。 如柱體(IFCColumn)、牆體(IFCWall)、門(IFCDoor)等建築物構造體均屬之。 2.性質(Properties) IFC 非常重視性質集(Pset_),用於定義共用的特定性能、材料類型、 環境性質等,在 IFC 的性質會歸納到 IFCP p.41
圖 2-4 IFCSpce 與 IFCDoor 物件屬性(Attributes)資料表  4.物件關係(Relationship between objects)

圖 2-4

IFCSpce 與 IFCDoor 物件屬性(Attributes)資料表 4.物件關係(Relationship between objects) p.42
圖 2-8  法規檢測的基礎流程架構

圖 2-8

法規檢測的基礎流程架構 p.48
圖 3-2  以 IFC 呈現法規分析架構

圖 3-2

以 IFC 呈現法規分析架構 p.51
圖 3-14 IFC 層級架構範例  二、建築技術規則設計施工編第 2 章分析架構  建築技術規則設計施工編第 2 章為一般設計通則,國內建築師在檢討建築 物的設計內容也以此編章條文為基準。分析一條建築技術規則的條文有幾個面 向要思考。首先必須要將各條文依照〝條〞、 〝項〞 、 〝款〞、 〝目〞予以編碼,因 為這涉及所有建築技術規則條文的串接,亦為法規條文自動化比對最基礎的編 碼工作。在臺北市、新北市政府的法規檢測系統已編訂一部分。以新北市政府 為例,是以法規自主檢查表的編碼為架構,這與建築技術規則的條文編

圖 3-14

IFC 層級架構範例 二、建築技術規則設計施工編第 2 章分析架構 建築技術規則設計施工編第 2 章為一般設計通則,國內建築師在檢討建築 物的設計內容也以此編章條文為基準。分析一條建築技術規則的條文有幾個面 向要思考。首先必須要將各條文依照〝條〞、 〝項〞 、 〝款〞、 〝目〞予以編碼,因 為這涉及所有建築技術規則條文的串接,亦為法規條文自動化比對最基礎的編 碼工作。在臺北市、新北市政府的法規檢測系統已編訂一部分。以新北市政府 為例,是以法規自主檢查表的編碼為架構,這與建築技術規則的條文編 p.63
圖 3-18  圖台顯示審查相關資訊-空間與色彩計畫  (由本研究繪製)

圖 3-18

圖台顯示審查相關資訊-空間與色彩計畫 (由本研究繪製) p.68
圖 4-1 法規分析與檢測系統程序關係圖  (由本研究繪製)  透過上圖所示,檢討運算邏輯中可以得到程式運算程序與運算方式(類型) 的相關說明,而在後面兩個欄位可以得到相對應的法規名稱 IFC 與相關參數, 這樣的法規分析結果可以提供給需要開發檢測軟體的系統或軟體開發商進行 系統發展的依據。BIM 建模操作或 BIM 軟體廠商可依據此編定的法規標準建 置樣版或提供參數建置方式,將法規參數標準化植入於 BIM 建模中,得到法 規資訊標準化的方法之一。  本次研究也針對法規運算邏輯進行實作分析,將法規分析結果進

圖 4-1

法規分析與檢測系統程序關係圖 (由本研究繪製) 透過上圖所示,檢討運算邏輯中可以得到程式運算程序與運算方式(類型) 的相關說明,而在後面兩個欄位可以得到相對應的法規名稱 IFC 與相關參數, 這樣的法規分析結果可以提供給需要開發檢測軟體的系統或軟體開發商進行 系統發展的依據。BIM 建模操作或 BIM 軟體廠商可依據此編定的法規標準建 置樣版或提供參數建置方式,將法規參數標準化植入於 BIM 建模中,得到法 規資訊標準化的方法之一。 本次研究也針對法規運算邏輯進行實作分析,將法規分析結果進 p.74
圖 4-4 產生虛量體(樓梯踏階面產生 190 公分虛量體)  (由本研究繪製)  4.執行程序:進行碰撞檢查  (虛量體與樓板進行交集碰撞檢查)  在法規分析的說明中有提到,法規檢測如果需要進行程式運算,其中 關鍵之一在於運算方式的確定,在這個案例中運算方式就是兩個不同物件 之間(需量體與樓板或樓梯)的交集碰撞,透過運算方式的確認,可以確定 成是在檢查時該如何進行判斷。  圖 4-5 進行碰撞檢查  (虛量體與樓板進行交集碰撞檢查)  (由本研究繪製)

圖 4-4

產生虛量體(樓梯踏階面產生 190 公分虛量體) (由本研究繪製) 4.執行程序:進行碰撞檢查 (虛量體與樓板進行交集碰撞檢查) 在法規分析的說明中有提到,法規檢測如果需要進行程式運算,其中 關鍵之一在於運算方式的確定,在這個案例中運算方式就是兩個不同物件 之間(需量體與樓板或樓梯)的交集碰撞,透過運算方式的確認,可以確定 成是在檢查時該如何進行判斷。 圖 4-5 進行碰撞檢查 (虛量體與樓板進行交集碰撞檢查) (由本研究繪製) p.76

參考文獻