國立交通大學
土木工程研究所
碩士論文
應用 IFC 於規範自動審查系統-
RC 柱構件之研究
Application of IFC in automated code checking
system against RC column members
研 究 生：周承禹
指導教授：洪士林 博士
應用 IFC 於規範自動審查系統- RC 柱構件之研究
學生：周承禹 指導教授：洪士林 博士國立交通大學土木工程學系
摘要
國際標準組織ISO 制定了許多的標準涵蓋各個領域，而標準的推行將隱含著技 術的領先與市場的競爭，所以標準的制定必須是嚴謹的。另一國際組織 IAI 則推動 以工程應用領域為主的資訊標準，在工程應用領域的資訊標準的推動下，解決了建 築 物 生 命 週 期 內 資 料 交 換 與 傳 遞 時 所 造 成 的 成 本 浪 費 問 題 ，IFC(Industrial Foundation Classes)標準格式就是目前工程界常用的標準格式之ㄧ，而剛興起的 BIM(Building Information Model)概念也是以 IFC 標準格式為基礎所發展出來的， BIM 概念有別於傳統 CAD 繪圖軟體，是以物件的方式來處理建築構件，將構件的 資 料 以 屬 性 的 方 式 存 在 物 件 中 。 新 加 坡 所 使 用 的 電 子 化 法 規 自 動 審 核 系 統 (e-PlanCheck)同樣也是以 IFC 檔案格式作為標準格式，上傳工程方案的圖檔，由電 腦依照法規來檢核，加快了審核的速度，從原本平均兩個禮拜的審查時間縮短為二 個工作天。 本研究希望利用BIM 的物件導向特性與 IFC 標準資料格式，發展一套線上的規 範自動審核系統，以我國的建築規範作為審核的標準，使用IFCEngine OCX&DLL 程式作為輔助開發的工具，這是一個免費的IFC 實體檔案存取的應用程式介面，我 們將以此為基礎，加以開發與應用，來完成我們的審查系統。但是基於時間的限制， 決定以「RC 柱構件」為主題，將 RC 柱構件的相關規範寫入系統，作為審核重點。 本研究額外撰寫了一個可設計柱構件之柱筋且符合IFC 格式的程式，來彌補目前建 築CAD 繪圖軟體對 IFC 鋼筋支援的不足，也讓本研究的規範自動審核系統有鋼筋 的IFC 檔案可以傳入作檢核。Application of IFC in automated code checking system
against RC column members
Student: Cheng-Yu Chou Advisor: Dr. Shih-Lin Hung Department of Civil Engineering
College Engineering
National Chiao Tung University
Abstract
Standards in International Organization for Standard (ISO) cover in several domains. Establishing and following standards implies leading of technology and competition of market. Therefore, creating standards to lead engineers or companies follow is an essential task in industry. International organization IAI also develops information standard about domain of engineering application primarily. Following corresponding standards for design results in cost saving of information exchange during the life cycle of a building. In engineering construction industry, IFC (Industrial Foundation Classes) is one of most frequently applied standard formats. BIM (Building Information Model) is a novel CAD concept, developed with the basis of IFC standard format. In BIM, any member for a building is viewed as an object including conventional drawing geometry data with material, analyzed results, etc. information and stored as attributes in the object.
The objective of this research is to develop an on-line automated code checking system with Taiwan's building regulation by using property of BIM and IFC standard format. Herein, freeware IFCEngine OCX&DLL program is employed as APIs platform (Application Programming Interface) to develop the system. Due to time constraints, this work only focuses on code checking of RC column members for a given building. Therefore, the corresponding building regulations about RC column members are re-coded in a data base. Although the entity of IFCReforcingBar had been defined and released in IFC, it is rarely applied in CAD system. Therefore, a program was developed for design an IFC-supported RC column member model with corresponding reinforcing bar in order to cover the drawback of the current CAD software. Reveal from study cases, the system demonstrated the feasibility of code checking for column members for a given building with IFC supported format.
誌謝
研究所兩年即將結束，在交大六年的求學生涯也將劃下句點，研究 所的學習方式有別於大學時期，不再是一味的接收別人給的，而是要有 獨立思考的精神，所以我在這兩年內成長了許多，也學到了不少，其中 最要感謝的人是我的指導老師洪士林博士，無論是在修課或是做研究的 方向，老師都給了我很大的自由度，使我能夠發揮所長，同時也從旁給 我指導與建議，所以本研究能夠順利完成，都要感謝我的老師，在此祝 福老師身體健康、青春永駐。 此外，我還要感謝土木所資訊組一哥沈秉廷，在我多次遇到難題而 不知道如何是好的時候，總是能夠給我ㄧ些意見，讓我可以迎刃而解， 同時也是本研究得以完成的關鍵人物。再來要感謝我的室友彥忠、文 凱、岳勳，陪我在無聊與苦悶的時候打打三國，舒解壓力，還有戰友智 仁、浚昇、聰吉、國維學長。感謝國際事務處的美女姊姊妹妹們，讓我 在打工的時候不會感到無聊。感謝同研究室的怡廷、世賢陪我度過熬夜 看洋基、趕論文的日子，感謝志銘、彥伶、智中學弟妹們，有了你們實 驗室多了歡笑。感謝家族的元旻學長、伯傑學弟、千惠學妹，給了我家 族的溫暖，也不忘督促我要順利畢業。最後我要說，有你們真好。目錄
摘要 ... i Abstract ...ii 誌謝 ...iii 目錄 ... iv 表目錄 ...vii 圖目錄 ...viii 第一章 緒論... 1 1.1 研究背景 ... 1 1.2 研究動機與目的 ... 3 1.3 研究方法 ... 4 1.4 論文架構 ... 5 第二章 研究相關知識... 7 2.1 IAI 與 IFC 簡介... 7 2.2 BIM 簡介 ... 9 2.3 CORENET... 11 2.3.1 CORENET e-Submission ... 12 2.3.2 CORENET e-PlanCheck... 12 2.3.3 CORENET e-Info ... 13 2.4 IFC 相關應用研究... 13 第三章 系統架構分析... 173.1 整體系統架構 v.s.實作系統架構 ... 17
3.2 IFCEngine OCX & DLL 介紹 ... 17
3.3 DLL 說明 ... 21 3.4 OCX 說明... 22 3.5 CGI 說明 ... 23 第四章 系統實作與開發... 25 4.1 檔案上傳系統 ... 25 4.2 IFC 格式分析與資料擷取... 26 4.3 柱筋 IFC 檔產生器... 27
4.4 IFC Engine DLL&OCX 新增功能 ... 29
4.5 梁柱板構件檢核之功能 ... 30 4.6 柱筋相關規範與檢核之功能 ... 32 4.6.1 檢核一: 柱筋之鋼筋比 ... 32 4.6.2 檢核二: 相鄰箍筋與繫筋之最大間距... 33 4.6.3 檢核三: 橫向鋼筋之間距 ... 33 4.6.4 檢核四: 彎鉤長度 ... 33 4.6.5 檢核五: 保護層厚度 ... 34 4.6.6 檢核六: 柱筋之搭接 ... 34 第五章 系統展示... 35 5.1 網頁架構展示 ... 35 5.2 系統環境 ... 36 5.3 梁柱板構件檢核功能展示 ... 37
5.4 柱筋檢核功能展示 ... 38 5.4.1 設計模型一 ... 39 5.4.2 設計模型二 ... 41 第六章 結論建議與未來展望... 43 6.1 結論 ... 43 6.2 建議 ... 44 6.3 未來展望 ... 45 參考文獻 ... 46
表目錄
表 4-2-1 一段 IFC 原始碼 ... 48 表 4-2-2 IFCCOLUMN 的定義... 48 表 4-6-1 縱向鋼筋之鋼筋比規定[18]... 49 表 4-6-2 橫向鋼筋之相鄰箍筋與繫筋之最大間距規定[18] ... 49 表 4-6-3 橫向鋼筋之間距規定[18]... 49 表 4-6-4 標準彎鉤之規定[18]... 49 表 4-6-5 鋼筋保護層之規定[18]... 50 表 4-6-6 柱筋搭接之規定[18]... 51圖目錄
圖 2-1-1 IFC 架構圖[5]... 52 圖 2-3-1 CORENET 的目的... 52 圖 2-3-2 傳統規範審核流程示意圖[17]... 53 圖 2-3-3 自動規範審核流程示意圖[17]... 53 圖 3-1-1 整體系統架構 OVERVIEW ... 54 圖 3-1-2 整體系統架構與實作部份比較 ... 55圖 3-2-1 左:拉遠功能(ZOOM OUT) 右:拉近功能(ZOOM IN)... 56
圖 3-2-2 物件旋轉功能(ROTATE) ... 56
圖 3-2-3 物件拖移功能(PAN)... 57
圖 3-2-4 RESET FRONT 功能，重置從物體正面觀察 ... 57
圖 3-2-5 RESET SIDE 功能，重置從物體側面觀察... 58
圖 3-2-6 IFC ENGINE DLL&OCX 的原有功能... 58
圖 3-4-1 IFC ENGINE DLL&OCX 運作過程... 59
圖 3-4-2 註冊 OCX 檔... 59
圖 3-4-3 將 OCX 檔、DLL 檔與 INF 檔壓縮打包成 CAB 檔 ... 60
圖 3-5-1 CGI 運作流程與原理 ... 60 圖 4-1-1 上傳系統流程圖 ... 61 圖 4-1-2 以訊息視窗來警告使用者只能傳入 IFC 格式的檔案... 61 圖 4-1-3 檔案上傳詳細內部運作流程 ... 62 圖 4-2-1 IFC 檔案的內容 ... 63 圖 4-2-2 IFCQUICKBROWSER 軟體開啟 IFC 檔 ... 64 圖 4-2-3 IFCCOLUMN 結構展開之樹狀結構... 64 圖 4-3-1 原始碼編譯成 CGI 之過程 ... 65 圖 4-3-2 表格資料與 CGI 技術內部參數傳遞過程 ... 65
圖 4-3-3 目前業界所用鋼筋圖與鋼筋表示法Ⅰ ... 65 圖 4-3-4 目前業界所用鋼筋圖與鋼筋表示法Ⅱ ... 66 圖 4-3-5 IFC 鋼筋種類 BARROLE 之列舉型態... 66 圖 4-3-6 IFC 鋼筋表面種類 BARSURFACE 之列舉型態... 67 圖 4-3-7 柱筋產生器執行時參數輸入的過程 ... 67 圖 4-3-8 命令列下編譯 RBAR.C ... 68 圖 4-3-9 命令列下編譯 UTIL.C... 68
圖 4-3-10 命令列下連結 RBAR.OBJ 與 UTIL.OBJ 成為 CGI 檔 ... 68
圖 4-3-11 IFC 資訊架構圖 ... 69 圖 4-3-12 加入鋼筋的實體 IFCREINFORCINGBAR，並連接 ... 69 圖 4-3-13 鋼筋 IFC 產生器所產生的 IFC 檔 ... 70 圖 4-4-1 新增功能-抽出柱資料 ... 71 圖 4-4-2 新增功能-抽出梁資料 ... 71 圖 4-4-3 新增功能-抽取鋼筋資料 ... 72 圖 4-4-4 新增功能-抽取樓板資料 ... 72 圖 4-4-5 隱藏物件功能(HIDE) ... 73 圖 4-4-6 顯示所有物件(DISPLAY ALL) ... 73 圖 4-4-7 被點選的物件變成黃色 ... 74 圖 4-5-1 大梁跨小梁示意圖，左為俯視圖，右為側視圖 ... 74 圖 4-5-2 梁身超過柱俯視圖，右邊兩根梁，梁身都超過柱 ... 75 圖 4-5-3 梁跨柱不在同一直線上之俯視圖 ... 75 圖 4-5-4 因為要做樓梯之故要去掉樓板 ... 76 圖 5-1-1 紅色框選部分為本研究實作的部份 ... 76 圖 5-1-2 系統實作首頁，可上傳所要檢核的 IFC 檔... 77 圖 5-1-3 點選瀏覽鈕可選擇要上傳的檔案 ... 77
圖 5-1-4 矩形柱與柱筋設計的表格網頁(RBAR.HTML) ... 78 圖 5-1-5 使用者設計的柱筋模型可點選下載 ... 78 圖 5-1-6 模型之 3D 展示 ... 79 圖 5-1-7 柱半透明化來觀察柱內部的鋼筋分布 ... 79 圖 5-3-1 以 ARCHICAD 繪製大梁跨小梁模型 ... 80 圖 5-3-2 以紅色來表示錯誤的地方，並在右方顯示警告錯誤的數目 . 80 圖 5-3-3 檢核出大梁跨小梁，在右方顯示對錯誤物件的描述。 ... 81 圖 5-3-4 以 ARCHICAD 繪製梁身超過柱模型 ... 81 圖 5-3-5 以紅色來表示錯誤的地方，並在右方顯示警告錯誤的數目 . 82 圖 5-3-6 檢核出梁身超過柱，在右方顯示對錯誤物件的描述。 ... 82 圖 5-3-7 以 ARCHICAD 繪製兩根梁跨柱不在同一直線上的模型 ... 83 圖 5-3-8 以紅色來表示錯誤的地方 ... 83 圖 5-3-9 檢核出左邊梁與右邊梁不在同一直線上。 ... 84 圖 5-3-10 以 ARCHICAD 繪製樓層樓板中空的模型 ... 84 圖 5-3-11 以紅色來表示錯誤的地方，並在右方顯示警告錯誤的數目85 圖 5-3-12 檢核出樓板可能會遭受剪力破壞。 ... 85 圖 5-4-1 柱與柱筋的設計參數表單 ... 86 圖 5-4-2 根據實際柱配筋圖，來設計一柱筋模型，如框選的斷面 ... 87 圖 5-4-3 選定柱配筋圖的某一斷面，填入參數，來設計柱筋模型 ... 88 圖 5-4-4 檢核出鋼筋比不符，並在右方顯示警告錯誤的數目。 ... 88 圖 5-4-5 點選紅色的錯誤物件後，右下會有對錯誤物件的描述 ... 89 圖 5-4-6 將視窗深入柱之內部查看鋼筋分布 ... 89 圖 5-4-7 跳出新視窗，顯示鋼筋比之規範 ... 90 圖 5-4-8 跳出新視窗，顯示繫筋與閉合箍筋相鄰各肢中心距之規範 . 90 圖 5-4-9 檢核出橫向鋼筋間距不符，在右方顯示警告錯誤的數目。 . 91
圖 5-4-10 點選紅色的錯誤物件後，右下會有對錯誤物件的描述... 91 圖 5-4-11 跳出新視窗，顯示橫向鋼筋間距之規範 ... 92 圖 5-4-12 檢核出彎鉤延伸長度不符。 ... 92 圖 5-4-13 跳出新視窗，顯示標準彎鉤之規範 ... 93 圖 5-4-14 檢核出保護層不足，在右方顯示警告錯誤的數目。... 93 圖 5-4-15 點選紅色的錯誤物件後，右下會有對錯誤物件的描述。... 94 圖 5-4-16 跳出新視窗，鋼筋保護層之規範 ... 94 圖 5-4-17 檢核柱筋鋼筋比，沒有錯誤 ... 95 圖 5-4-18 檢核相鄰箍繫筋的最大間距，沒有錯誤 ... 95 圖 5-4-19 檢核橫向鋼筋間距，沒有錯誤 ... 96 圖 5-4-20 檢核鋼筋彎鉤長度，沒有錯誤 ... 96 圖 5-4-21 檢核保護層厚度，沒有錯誤 ... 97 圖 5-4-22 跳出新視窗，柱筋搭接之規範 ... 97
第一章 緒論
1.1 研究背景
國際標準組織ISO(International Organization for Standard)已將開放文 件格式ODF(Open Document Format)列為正式的國際標準，而ODF可運用 延伸標籤語言XML(Extensible Markup Language)來定義工作的文件格 式 ，例如文字、圖表、繪圖文件等等，透過XML對文件的定義(Schema)， 使得文件的資料可以獨立出來不受應用程式的限制，並依資料標準來相互 交換使用。這個文件標準已經應用到多種不同的專業領域，聯合國的貿易 簡 化 與 電 子 商 務 中 心UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)正如火如荼的在推動國際資訊交換標 準的訂定與推廣，其範圍包括國際貿易、軍事、醫藥、化學、一般商務、 物流、營造建築業等等，也遵循ISO程序推動國際認同成為國際標準。
而另一國際組織IAI(International Alliance for Interoperability)則推動以 工程應用領域為主的資訊標準，重點著重在工程設計的本體，也就是3D的 幾何資訊模型，其資料標準為IFC(Industrial Foundation Classes)格式，目 的不僅是要提高工程設計的效率及正確性，也透過幾何的資訊模型，在設 計過程中不同的專業領域，如建築設計、水電空調、管線配置、成本估價、 營建管理等等，透過此標準格式互相使用工程的資料與訊息，達成資訊共 享與再利用。此IFC格式顯然已成工程業界的標準，許多工程應用軟體已開 始 提 供IFC格式資料的輸出輸入介面，例如AutoCAD、MicroStation、 ArchiCAD等等。從上面敘述可看出標準的推行將隱含著技術的領先與市場 的競爭，可謂兵家必爭。 由這些國際的走向趨勢及全球性的資訊交換組織來看不難發現，在全球
化、國際化的發展下，跨國界、跨企業、跨產業、跨專業的資訊交換需求 與日俱增，由國際資訊交換標準組織所制訂的資料格式也顯得格外重要， 在這強調跨領域、跨平台、跨國際的資訊交換強力趨勢下，是各領域應努 力的方向[1]。
而由IAI提出的建築資訊模型(BIM, Building Information Model)是以3D 物件代表建築物各元件的資料模型，在建築物整個生命週期內所有的資料 與訊息都儲存在這個模型中，在建築生命週期裡任何領域或任何軟體都可 以在這模型裡獲得所需的資料與資訊，而這個資料的標準儲存格式就是 IFC。一份來自英國的報告表明，在早期，建築項目的成本大約有30%損失 在工程建設的訊息交流上[2]，IFC資料標準的出現解決訊息交換與共享的問 題。而目前國際間，各工程專業領域的設計知識亦多以IFC的格式儲存，故 IFC已廣泛成為BIM的資料交換格式及建構BIM的基礎。
新加坡推行的CORENET (COnstruction and Real Estate NETwork)系 統，中譯為建築與房地產網路，在2004已達完善階段，至今已成熟營運， 這系統以IFC資料格式為基礎，發展電子化檔案繳交(e-submission) 系統與 自動化的線上規範審核(e-plan check)系統，並提供線上審查進度查詢，有 了這個系統，建築設計公司在呈交建築藍圖時，無須走遍政府所有部門一 一辦理申請手續，可以透過電子化的網路上傳繳交系統遞交建築藍圖、結 構設計圖與申請各種許可證明。此電子系統每年為新加坡政府、建築公司 與業主節省了大筆的金錢與時間，加快了審核的速度，從原本平均兩個禮 拜的審查時間縮短為二個工作天[3]，對於各國的土木建築業來說，是一個 很值得仿效學習的案例。
1.2 研究動機與目的
基於上述的國際標準發展之背景，本論文研究動機分敘如下:
動機一，在BIM 概念的推行下，許多的 CAD 繪圖軟體運用 BIM 將圖 形資料與文字資訊包含在一個模型中，不再像以前用標注或註解等方式來 描述物體，而是將資訊變成有意義的物件屬性記錄在物件中，本研究就是 要利用這種模型中搭載圖形資訊的方式，藉由程式來擷取出模型裡的資 料，進而對於此模型進行分析。 動機二，在了解新加坡的營建規範電子化自動審查系統後，是否台灣 也可以發展一套這種建築營建規範自動審查的系統？不僅節省了人力與 成本，縮短審核的時間，更可以使工程有效率的運作下去，有這麼多的好 處，我們也應該仿傚之，開發一個合適的自動審核系統。 動機三，資訊的標準化是一種必然的趨勢，本研究選擇越來越受歡迎 的IFC 資料標準格式來當作系統程式讀入的檔案格式，如此一來，多款建
築CAD 繪圖軟體只要輸出成 IFC 檔案格式(.ifc)都可以由系統的程式來讀 入進行檢核。 動機四，雖然IFC 對各建築構件都有完整的定義，包括鋼筋部分，但 是目前的 CAD 繪圖軟體都沒有相對應的鋼筋元件，所以也無法使用 IFC 格式來描述鋼筋，這是非常可惜的，所以如果能在現存的IFC 檔自行加入 IFC 對鋼筋描述的實體，是否可行還是未知的，但是是值得研究的。 綜合以上各點，本研究的目的是要利用BIM 的特性與 IFC 的標準化， 開發一個營建規範自動審查系統，以我國的建築規範為審查準則，將建築 CAD 繪圖軟體設計的 3D 模型圖檔傳入系統，作與規範比對的各項審核， 但是由於時間、資源、技術等等的限制，加上結構審查項目繁多，決定先
將重點放「RC 柱構件」的部分，以「RC 柱構件」作為規範審查的對象， 將柱構件的相關規範內容寫入系統。並撰寫一個程式用來設計鋼筋構件， 最重要的是此程式將以IFC 對鋼筋的定義之格式來儲存，以彌補目前 CAD 繪圖軟體對 IFC 支援之不足，當然也可藉此程式，設計包含鋼筋的柱構 件，傳入系統做柱構件之柱筋的檢核。
1.3 研究方法
想要對建築模型作審核，必定要知道模型中物件的資訊(如座標、尺寸 等等)，所以我們要從有搭載圖形屬性資訊的 BIM 模型裡擷取出所需要的 資料，要擷取資料就必須了解 IFC 這檔案格式的定義與語法(schema)， 若要自己寫程式來解析IFC 檔案實在是一個龐大的工程，所幸網路上已經有一些IFC 的研究者開發出許多 IFC 相關的應用程式，其中 TNO 公司所 開發的應用程式最能符合本研究的需求，也適合本研究的目的做深入的應 用。TNO 公司所提供的應用程式介面(API) ─IFC Engine OCX&DLL，這
是一個免費的IFC 實體檔案存取的應用程式介面，而此應用程式介面已經
提供了解析(parse)IFC 檔案的函數，所以可以直接使用這些函數就可以擷 取IFC 檔案中的一些屬性或資料，追蹤(trace)它的 C++ source code，了 解其函數的意義與功能，再進而改寫或增加所需功能的函數，將規範所規 定的內容寫進程式裡，輸入擷取到的資料進行檢核，本研究主要是針對 「RC 柱構件」部份進行檢核，由於 ArchiCAD 等繪圖軟體無法畫出支援 IFC 格式的鋼筋，這部份將另外寫一個可以設計鋼筋嵌入柱子裡並符合 IFC 檔案格式的程式，在此暫時稱之為柱筋產生器，此程式由 C 語言撰寫 成，並以 CGI 的方式由網頁表格填入鋼筋與柱子的資料，產生一個使用 者所要求的 IFC 檔，至於其他檢核梁柱不合理的案例模型，則可以由
ArchiCAD 軟體來繪成，並匯出成 IFC 格式，再由 IFC Engine OCX&DLL 此應用程式讀入，進行一系列的審核。
1.4 論文架構
本論文其餘各章的內容蓋述如下:
第二章:說明與本研究主題相關的知識以及文獻，內容有 IAI 公司所推 行的IFC 資料格式與 BIM 建築資訊模型的介紹。新加坡 CORENET 系統 的深入介紹。
第三章:本章節在說明整體系統架構之概念與有實作的系統架構內 容，並介紹用於開發系統之程式IFC Engine OCX&DLL 的基本功能，並 說明OCX 與 DLL 的原理，最後說明系統用到的網頁技術 CGI。
第四章:本章節在說明開發系統的過程，以動態網頁技術 JSP 實作檔 案上傳的功能，改寫與新增應用程式介面IFC Engine OCX&DLL 的功能，
再分析 IFC 格式來撰寫柱筋產生器並用 CGI 技術應用於網頁，之後說明 梁柱板空間分布不合理的審核演算法，最後說明如何將規範中的柱筋規範 寫成程式來檢核。 第五章:本章節先對實作系統做概觀說明，再來用 ArchiCAD 繪製一些 實際模型，傳入檢核系統做檢核，並展示結果，最後用系統開發的柱筋產 生器產生柱筋模型帶傳入系統做檢核，並展示結果。 第六章:此章節綜合了幾項結論，並對於可改進的部份做了建議，更進 一步做出對於未來的期許。
第二章 研究相關知識
本章節介紹與本研究相關的知識及資訊，包括 IAI 的成立目標及發展
史，IFC 資料格式的發展與簡介，BIM 的內容說明及優點，最後介紹新加 坡所推行的CORENET System。
2.1 IAI 與 IFC 簡介
IAI 全名為 International Alliance for Interoperability，目標為致力於全 世界範圍內建築與設備管理的資訊共享，提供一套統一標準的資訊共享的 過程，並對工業基礎類別進行定義，促進整個建築生命週期內訊息的交 流，時間的縮短，以及品質的改善。 IAI 的發展起源於 1994 年，美國 12 家公司共同研究不同應用軟體在 協同工作的可能性，他們覺得協同工作是可行的，而且這種協同工作能力 會帶來可觀的經濟效益。1995 年克服了 kernel 的問題後他們在建築工程 系統研討會上展示了他們的研究成果，這成果就是一套簡稱IFC 的資料交 換格式，IFC 格式使得資料格式有了依據的標準，資料的標準化、一致性 使不同軟體間可相互交換資料無需再各自建立資料。很多與會的組織對此 都表示出了濃厚的興趣，有意加入，希望能共同研究。之後，他們決定對 外開放，對建築工程與設備管理領域組織開放，對所有軟體開發商開放， 同年10 月，他們在北美成立 IAI 組織。IAI 成員們很快發現這是全球工業 的問題，隨後他們將軟體間協同工作的思想推廣到其他國家，很快的其他 國家也相繼成立了 IAI 分部。1996 年在倫敦召開了第一次的 IAI 國際會 議。1997 年 IAI 發表了第一板 IFC1.0。 在IFC1.0 資 料 標 準 化 的 範 圍 主 要 包 括 下 列 四 個 領 域 ： 建 築
(Architecture) 、 暖 氣 流 通 與 空 調 (HVAC) 、 營 建 管 理 (Construction Management)、設施運作與管理(Facilities Operation and Management)， 清楚界定IFC的資料標準並非單一應用領域的資料結構，而是跨設計、施 工、營建、管理、維護等跨平台也跨專業領域的資訊結構。之後發展之IFC1.5 隨即將此一標準資訊結構匯入繪圖商用軟體，從此進入商用工程設計市 場，目前IFC資料結構已重新改板為IFC2.0，並有多種延伸板本IFC2x板 (IFC2.0Extension)。目前最新板為2x3 Final，本研究所用的IFC板本皆為2x3 Final。IFC各板本所能容納各專業領域的程度以建築之資訊最多，營建管 理、物料庫、營運維護、估價發包、水電空調分析的資訊則次之，而以地 理資訊系統(GIS)的資訊最少，但目前將GIS納入IFC是IAI近年來推動的重 點之ㄧ[4]。
IFC (Industry Foundation Classes)中譯為工業基礎類別，是一種塑模 語言，目前主要用於建築、營建工程與設備管理等領域，目的在於讓各種
在此領域內的應用軟體可以遵循同一種資料格式，或使領域內不同的BIM
系統有一個資料交換的標準。
IFC 以物件導向(Object Oriented)為基本概念，參考了 STEP 部分標
準，為了實作考量也參考了物件導向語言C++程式語言的一些特性。以架
構而言可以分為四個層次，由上而下分別為: 領域層(Domain Layer)、共 享交換層(Interoperability Layer)、核心層(Core Layer)、資源層(Resource Layer)，每層分別定義了不同的種類的資料類型 (Data Type)與實體 (Entity)，如圖 2-1-1 所示[5]。
領域層(Domain Layer)
這 層 為 定 義 AEC/FM(Architecture ,Engineering , Construction and Facilities Management)領域內各專業領域的實體，包含:建築、結構分析、
營建管理、設施管理、機電設備、水電空調、配管工程等等專業領域的實 體。 共享交換層(Interoperability Layer) 這層定義能夠在 AEC/FM 領域內做資訊共享與交換的共同實體，例如: 梁、柱、門、窗、空間等等資訊。 核心層(Core Layer) 這層定義IFC 基礎的實體，此層的實體定義了許多共同的介面，它們可被 資訊交換層或專業領域層的實體參考或繼承。 資源層(Resource Layer) 這層定義較一般性的實體，類似STEP 的整合性一般資源，通常它們都是 依附或參考在較高層次的實體上。 目前支援 IFC 格式的建築 CAD 繪圖或分析軟體有逐漸增多的趨勢， 就目前所知的有SAP2000、ArchiCAD、AutoCAD、MicroStation 等軟體 支援，但是IFC 檔案於軟體間的傳遞會有遺漏的情形，同一個軟體匯出成 IFC 格式再以 IFC 格式讀入都可能會有少許遺漏的情況，各軟體間也由於 支援IFC 程度的不同，有些元件沒定義或定義不同，造成資料遺漏或錯誤 的情況，所以這一部份是IFC 還不健全的地方，也是未來各 CAD 軟體商 需要努力的地方，在本研究中只使用 ArchiCAD 軟體來繪製所需要的模 型，不需要在軟體間轉換，減少了資料遺失的情況。
2.2 BIM 簡介
週期中各專業領域的設計者提供該領域所貢獻的建築資料與專業知識，把 這些資料儲存起來就是一個建築資訊模型，其他領域可從建築資訊模型中 獲取所需的資料與欲處理的建物的資訊，達到資料共享與資訊再利用，所 以建築資訊模型可以說是一個資料庫，將該建築物生命週期裡的所有資料 與訊息存在其中，也是各個專業領域設計者知識與經驗的累積所匯集的知 識庫。而建築 CAD 繪圖軟體從 2D 平面圖形的表示轉變為 3D 的模型呈 現，這種建築資訊的模型化也是BIM 的另一種意義。 BIM 概念與傳統 CAD 繪圖軟體的比較 傳統建築 CAD 軟體繪圖用點、線、標注或註解來表示圖形之建築資 訊。例如梁之配筋圖，從這些圖中無法直接取得有意義的資訊(例如梁或 鋼筋斷面尺寸、長度等等)，必須經由人為的判讀或計算才能得到圖檔裡 的資訊，然而 BIM 的世界裡，梁、柱、板、牆、門、窗等等都是一個個 獨立物件，它們的屬性就是資訊，可以直接取得，這樣一個一個物件組合 起來，改變各物件的屬性來達到想要繪製的結果，這樣就是一個建築資訊 的模型。 BIM 的優點 建築資訊模型(BIM)，藉由建立3D的幾何模型也同時建立資訊模型的成 果，其所帶來的優點有[6]: 1. 工程設計具體化：可將設計方案具體化、視覺化、3D化，也就是可以 以動畫或虛擬現實場景的方式呈現。 2. 避開工程風險：在實際進入施工階段之前可就構件衝突問題或有錯誤的 地方事先偵測並作預防性的處理。 3. 物件數量計算：可直接從模型中抽取必要資料並加以統計，將其表格化
的呈現，例如門窗數量的計算統計，可以輸出以excel表格的方式表示。 4. 變更設計時保持一致性與協調性：建築資訊模型能自動地使專案的所有 資訊協調一致，建築模型的任何改動都會立刻反映到整個專案產生的檔 案中。 5. 提昇設計品質，縮短設計週期，效率提高：設計者更能具體掌握其設計 成果的視覺效果、造價成本等，而且由於在使用的同時動態生成專案的 有關資訊錯誤和資訊遺失會大幅度減少，因此提高了設計品質，減少了 資料往返的次數。 6. 屬性資料的直接使用：有別於傳統CAD軟體，模型的資料與訊息直接以 屬性的方式存於BIM中，所以可以很方便的取用，無須經過人為的判讀。 7. 工程資料再利用：可將設計資訊完整的保留在建築資訊模型之中，從早 期方案階段的構思到詳圖設計階段的最終變化都得予以保存，方便其在 整個工程生命週期中各個階段來使用。
2.3 CORENET
CORENET全名為COnstruction and Real Estate NETwork，中譯為建 築與房地產網路，主要以資訊科技為主，是新加坡國家發展部所發展的一
個計畫，CORENET的目標是發展一個整合建築生命週期的四個基本過程─
設計(Design)、實現(Procure)、建造(Build)、維護(Maintain)的資訊科技系 統(如圖 2-3-1)，而在設計這階段裡已經發展了三個系統且已成熟的運作， 這三個系統分別為CORENET e-Submission，CORENET e-PlanCheck， CORENET e-Info[7]。
2.3.1 CORENET e-Submission 是一個以網路為基礎的上傳繳交系統，可透過這系統上傳計畫方案的圖 檔(例如設計圖、工程圖、建築圖等等)與文件給工程審核機構，做各方面的 審核，包括計劃審核、建築審核、結構審核、管線空調與防火安全規範等 等。 e-Submission的優點: 1. 數位資料取代了紙本資料，減少了印刷與紙張，對於全球減碳節能的今 日，可以說是非常重要的。 2. 一天24小時，一個禮拜7天，任何時刻只要你可以上網都可繳交資料， 打破以往只能在上班時間繳件的限制。 3. 同一份文件可能要送到多個審核單位(如圖 2-3-2)，所以需要浪費很多 人工來收件，e-Submission算是一個虛擬的收件者。 4. 文件在審核單位之間的傳遞也是以人工傳遞，這不僅增加人事成本，也 增 加 人 為 遺 失 資 料 的 可 能 性 ，e-Submission解決了這些問題(如圖 2-3-3)。 2.3.2 CORENET e-PlanCheck 這系統的目的是提供一系列的資訊科技應用程式，來自動地檢核透過上 述e-submission所上傳的建築相關電子圖檔，是否有符合規範的要求，這部 份也是本論文所欲探討研究的議題與實作的重點。 e-PlanCheck的優點[8]: 1. 自動檢核取代了人工檢核，傳統人工檢核是人力密集且耗費時間的工
作，能以電腦來取代可以說是省時又省工。 2. 審核人員對規範的解釋不一致，當規範語義有模糊不清或模稜兩可時， 不同的審核人員可能有不同的審核結果，將規範寫入程式後，系統會以 相同的標準來審核，不會有上述的情況發生。 3. 規範審查是件乏味的工作，以人工來檢核可能會發生人為檢查的失誤， 或審查人員被收買、放水或故意刁難的情形，審查自動化後就可避免以 上的情形，且可以刺激建築業，使其朝向採用物件導向的電腦輔助設計 (CAD)。 2.3.3 CORENET e-Info 本系統提供一個中央的儲藏庫，儲藏建築物或結構等相關的資料，之前 上傳過的資料，可以在任何時間、任何地點透過網際網路來存取。此儲藏 庫也儲存新加坡建築規範與新加坡各房屋與建築管理單位的公告，會自動 地寄送關於房屋與建築業的新聞消息給它的訂閱者。
2.4 IFC 相關應用與研究
受到BIM 觀念廣為被採用的影響，IFC 這建築資訊交換標準也受到矚 目，成為近年來熱門的檔案標準格式之一，研究 IFC 與 BIM 的相關應用 與文獻也就紛紛出爐，本研究參考了幾篇IFC 相關的研究的內容，得到了 一些靈感與方法來幫助研究，使得本研究得以順利進行。Lee、Chin 與 Kim(2003)發展一個整合的資訊系統稱為 DIMS(Design Information Management System)，著重在於以 IFC 為基礎的繪製資訊之 呈現，此系統結合了排程、評估估價與結構工程資訊，整合來自各方資訊
的 DIMS 透過對建築元件階層式的分類可從多個方面呈現計畫的資訊， DIMS 也可計算每一種建築構件的數量，並幫助使用者於 3D 系統之中更
清楚辨認出與之相對應的3D 圖形物件[9]。
Halfawy 與 Froese(2005)使用 IFC 於 AEC 專案資料與進程之整合， AEC 工業整合的趨勢正增加專案系統的實作與使用的需求，標準資訊模
型被廣泛地當作是主要的發展整合 AEC 系統的科技，多數重要的模型也
都是以IAI 所發展的 IFC 作為標準之資料格式，這篇文章呈現了 IFC 類別
的實作，用來完全地支援AEC 專案的資料與進程，也討論連結專案設計、 排程、花費細項與不同系統間雙向的資料交換[10]。 曾旭東與譚潔(2006)發表對 IFC 標準的建築結構模型的自動生成，建 築模型之自動生成為符合多種結構分析與設計軟體的結構模型，並通過實 例驗證此研究方法的實用性與可行性，結果此方法為各種設計軟體間訊息 的交換與共享提供了一種通用的解決方案，為企業內部實現建築設計集成 化提供了技術保證。最後討論了該研究方向中對於IFC 標準之建築模型的 結構偏心、節點連接、荷載處理 等問題以及後續研究方向[11]。 沈秉廷(2007)運用物件導向技術於 IFC 建築資訊，此研究由物件導向 的觀點探討 IFC 規格設計與實作方法，介紹 IFC 實體檔案存取應用程式 介面並探討其IFC 資訊存取方式。此研究運用物件導向技術，撰寫程式將
IFC Entity 規格轉換為.Net Framework 類別(Class)，再以類別庫(Class Library)封裝。此類別庫提供較直觀的 IFC 應用程式開發方式，並能夠運 用物件導向於系統開發。最後使用所建置之類別庫開發以外掛(Plug-In)為 架構的IFC BIM 系統，並開發一些外掛(Plug-In)元件進一步示範如何應用 類別庫，例如: 3D 建築模型瀏覽、梁柱斷面資訊瀏覽、建築物框架建模等 等外掛(Plug-In)元件[12]。
Faraj 與 Alshawi(1999)等人發展一以網頁與 IFC 為基礎的協同工作的 結構工程運算環境，此研究討論一個給結構協同工作之發展與實作的環
境，此環境為英國Salfor 大學中一個為人所熟知的以網頁為基礎的共享專
案 的 環 境 ， 簡 稱 WISPER (Web-based IFC Shared Project EnviRonment)，這環境有三層的架構，分別為使用者介面、商業邏輯與
資料庫，這環境支援 CAD 設計、視覺化的虛擬實境、評估、專案、詳細
計畫書、供應商資訊，可說是一個網頁與IFC 為基礎的分散式電腦整合環
境。WISPER 使專案資訊透過 STEP PART 21 來進行檔案交換，透過 IFC 進行資料庫共享，同時很多網頁允許遠端互動，例如存取檔案，這提供了 很大的彈性與可攜性，因此使得結構專業人員能夠分開地執行與管理他們 的項目[13]。 邱奎寧與王磊(2004)在「IFC 標準的實現方法」中概要地分析了軟體 中的 IFC 標準之實現方法與過程，IFC 標準即將作為中國大陸的國家標 準，所以將IFC 標準的應用於開發項目會涉及到的相關問題作探討，IFC 標準實現方法的內容有三個步驟:技術準備、方案設計、一致性測試。技 術準備主要要解決三個問題:了解 IFC 的概況、學習 EXPRESS 語言、熟
悉IFC 整體框架。由於大陸地區之建築 CAD 軟體開發商普遍不了解 BIM
意義，對建築資訊的交換與共享也不熟悉，而這兩者正式IFC 的內容，所 以首要課題為瞭解IFC 的概況。再者，IFC 標準本質為建築物與工程數據 的定義，它採用了 EXPRESS 語言來描述與定義，學習 EXPRESS 語言 可幫助我們更容易了解IFC。而 IFC 的總體架構是分層的與模組化的，對 於一般的應用開發只需要熟悉即可，不需要全然了解。方案設計的主要內 容是設計資訊的共享與交換的方式，一是未知系統只要能夠使別IFC 格式 的文件就能夠與本應用系統共享與交換資訊。另一是透過SDAI(Standard Data Access Interface)，未知系統透過此介面也能與本應用系統共享與交
換資訊。最後是一致性測試，要對實現IFC 標準的應用軟體進行測試，無 論何時、何地，測試結果都必須一致，並透過紀錄來檢查測試步驟的正確 性，一致性測試在資訊共享與交換的“質”與“量”給予保證[14]。
第三章 系統架構分析
本章將對整體理念的系統架構作概觀的介紹，對要開發實作的系統架 構進行分析與說明，並做兩者的比較。之後對開發工具用IFCEngine OCX & DLL 做功能的介紹，並說明 OCX 與 DLL 原理，再對製作網頁用到的 CGI 技術應用做說明。3.1 整體系統架構 v.s.實作系統架構
本研究的整體系統架構如圖 3-1-1 所示，系統入口是一個登入(login) 系統，為了保護系統的安全以及使用者管制，亦或是分辨使用者的身分(例 如建築師、結構技師、業主等等其他相關人員)來開放不同的存取權限或 功能項目，而設置這樣一個需要輸入帳號密碼的功能。登入後，可以依使 用者權限的不同，有不同的功能選項，例如建築設計師可以上傳建築圖檔 進行規範審核、構件數量計算與估價、工程進度與排程等等，其他功能有 如查閱最新規範、建材最新單價、業界最新消息、結構分析等等，此完整 的系統將會涵蓋很大的範圍。 然而基於時間的限制，本研究實作的系統架構如圖 3-1-2，只佔整體 系統架構的一部分，此部分完成了上傳檔案系統與RC 柱筋的檢核。並額 外開發了產生柱筋IFC 檔的程式，以彌補目前建築 CAD 軟體無法繪製鋼 筋IFC 檔的不足，本研究為整體系統架構的實現跨出第一步。3.2 IFCEngine OCX & DLL 介紹
(.ocx)與 DLL 檔(.dll)兩部分，是一個 IFC 資料存取的應用程式介面(API, Application Program Interface)，目前最新板本為 1.02，但是在實作時 1.02
板本尚未釋出，所以整個實作過程都是用 1.01 板本，1.01 板本可支援 IFC2x2 與 IFC2x3。 TNO 公司免費提供學術研究及非營利用途使用，若要使用在商業用途 則必需付費。此應用程式為Windows 平台下的 DLL 元件，使用 Microsoft Visual C++編譯器建置，使用此 API 需要 C 程式語言的基礎，因為其用到 許多指標(pointer)來操作資料，而且 Visual C++與一般 C++尚有些許不 同，這部份可以上網msdn( Microsoft Developer Network )或找相關書籍 參考。
IFCEngine DLL 根據 Standard Data Access Interface (SDAI, ISO 10303-22)設計，SDAI 定義為以 STEP 建模之模型的資料存取介面，這 些資訊存取的方式相當低階，使用上繁雜，但效率高[15]。
IFCEngine OCX 為開發出來更容易使用 IFCEngine DLL 的 ActiveX
控制項，這ActiveX 控制項能夠嵌在其他應用程式上，本研究即是將 OCX
嵌在IE 網際網路瀏覽器應用程式中。而在此 OCX 中有 3D 模型瀏覽的 3D viewer 之功能，所以若要使用 IFCEngine OCX 必須安裝有 DirectX 8 或 更新的板本。IFCEngine OCX 只支援部份的 SDAI 功能，但是 IFCEngine OCX 是公開原始碼的，所以使用者能夠任意修改或是新增所需功能[16]。
以下介紹一些有用到的API: sdaiOpenModelBN
用於開啟一個檔案，需指定檔案的所屬的schema，回傳 ModelID。這邊
sdaiCloseModel
用於關閉一個檔案，但這個檔將不被儲存。這邊我們用來將已開啟的IFC
檔關閉。
initializeModelling
用於在程式的3D viewer 啟動前做初始化的動作，決定 3D viewer 的規模 (scales)，也就是 3D 瀏覽器的大小，並回傳儲存 indices 與 vertices 所需 的空間。
sdaiGetEntity
從Model 中藉由 Entity 名稱取得 Entity 物件，回傳 InstanceID。
sdaiGetEntityExtentBN
從Model 中藉由 Entity 名稱取得一組 Entity 物件，回傳 aggregate ID， 再藉由engiGetAggrElement 函式去取得 Instance ID sdaiGetMemberCount 傳回特定聚合 Instance 的成員數目。在程式中有些 Instance 的資料型態 是由多個 Instance 所組合形成的聚合型態(aggregate)，我們要知道是由 多少個 Instance 所聚合才有辦法抓取聚合 Instance 中的特定成員，此函 數輸入aggregate ID 就可得知是由多個 Instance 所組合。
sdaiGetAttrBN
藉由 Instance ID、屬性名稱及類型取得該屬性的內容。這是一個很重要
的函數，我們使用它來擷取Instance 的屬性。
IFCEngine OCX&DLL 所提供的基本功能，可分成兩部份，第一部份 是3D viewer 展示，第二部分是雙擊(double click)物件就可以顯示該物件 的基本屬性。
1. 3D viewer 展示
建築CAD 繪圖軟體發展至今，幾乎都支援 3D 展示瀏覽的功能，就是
3D viewer，這可以方便我們以立體的角度來看我們從平面設計的物件， 以確保畫出來的是我們所想要的，在IFC Engine OCX&DLL 應用程式介 面中也有提供3D viewer 的功能，此 3D viewer 也提供一般 3D 瀏覽時所 提供的功能，有拉近拉遠(zoom 如圖 3-2-1)、旋轉(rotate 如圖 3-2-2)、 拖移(pan 如圖 3-2-3)等等功能，並有額外的兩個功能:正視觀察(reset front 如圖 3-2-4)與側視觀察(reset side 如圖 3-2-5)，讓我們方便調整方 向以想要的角度來觀察物體。
而將檔案載入3D 展示瀏覽器的是一個“Load IFC File＂的功能，內 部的語法是將“fileName＂這個變數的值指向 IFC 檔所在的網路位置，例 如 fileName='http://www.ifcbrowser.com/test.ifc'，所以如果要讀入新的 IFC 檔案，只需要將新檔案的網路位置傳給 fileName 即可。
2. 基本屬性擷取
進而呼叫 OCX 中的 doubleclick()這函數，此函數會回傳被滑鼠所點到的 物件ID，有了這 ID 就可當作參數帶入一些函數中求得該物件的一些基本 屬性，例如 sdaiGetStringAttrBN(id,attribution)，而一般物件基本的屬性 值有GlobalId、Name、Description、ObjectType 等等(如圖 3-2-6 所示)。 不過這些預設提供的資料對我們來說是不夠的，所以我們必須改寫或自行 新增一些函數來擷取想要的資料，以利我們做一些運算與比較。
3.3 DLL 說明
DLL 全名為 Dynamic Link Library，中文譯為動態連結函式庫，DLL
也可以說是一種執行檔，但是 DLL 中的程式碼只能被其他執行檔或 DLL 執行，換一個角度看 DLL 扮演提供函數服務的角色，相對於動態連結函 式庫，我們寫的程式大多是靜態連結的，因為函式的程式碼一經複製到執 行檔就不能做改變，如果要更改，就必須重新編譯(compile)及連結(link)， 靜態連結會在編譯階段就將程式所需要的函式加執行檔中，執行檔所須的 記憶體空間自然就會增加；因此隨著系統越來越複雜，所需要的函式越來 越多，這就衍生二個問題: 1. 當系統功能越複雜,隨著引用的函式數量增加,執行檔需要更大的 記憶體空間才能執行。 2. 不同的執行檔無法共用相同的函式，必須在各自的程式碼中複製 同樣的函式，形成浪費。 為了改進靜態連結所產生的缺點，在 UNIX 以及 Linux 作業系統上，
就逐漸發展出分享式函式庫(Shared Library)，而 Win32 平台則發展出動 態連結函式庫(Dynamic Link Library)。由於動態連結函式庫的函式的程式
碼是在應用程式載入或是執行階段才與應用程式相連結，也就是說，函式 的程式碼與應用程式的程式碼在編譯時彼此是各自獨立成不同的檔案。與 靜態連結相比，由於函式被分離成個別的動態連結檔，應用程式所佔的記 憶體空間自然就縮減了，也因為獨立的動態連結檔，才可以讓不同的應用 程式共用相同的函式，作業系統能更有彈性地調配資源。
3.4 OCX 說明
OCX 是一種 ActiveX 控制項，可由 VC、VB 或 Delphi 等程式語言來 開發。ActiveX 控制項是一種可以被執行的檔案，像是 OCX、DLL 或是 EXE 檔案，除了 EXE 檔案外，其它如 OCX 或 DLL 必須要在其它的應用 程式下才能被執行，這些應用程式如VB 的表單、IE 網頁瀏覽器或是 Office 軟體， ActiveX 的概念就如 Netscape 的 PlugIn 的概念一樣，都是程式需 要某一項額外的功能時，就把一個可執行的檔案掛入執行，這樣就能擴充 程式本身做不到的功能。 ActiveX 控制項的特點是：一般軟體需要用户端下載然後執行安装， 而ActiveX 控制項是當用户瀏覽到特定的網頁時，IE 瀏覽器即可自動下載 並提示用户端是否安装。但是ActiveX 控制項安装前必須經過用户端的同 意及確認。
在本研究中就是將OCX 嵌在 IE 中，ActiveX 控制項 OCX 需要登錄註 冊後才可以使用，在IFCEngine DLL&OCX 此應用程式介面裡，已經將註
冊 OCX 的語法寫成一個批次檔(.bat)，我們只要執行該批次檔就可以將
OCX 檔註冊，其實註冊的語法很簡單，在命令提示位元切換到 OCX 所在 資 料 夾 ， 輸 入 regsvr32 filename.ocx 即可。運作方式如圖 3-4-2，
CAB 格式為微軟的封包檔，為一壓縮封包，可包含多個相關的檔案。封 包檔格式為最佳的壓縮率。IFCEngine DLL&OCX 中也將打包 CAB 檔的
指令寫成一個批次檔，我們只要執行該批次檔就可以將OCX 檔、DLL 檔
與INF 檔壓縮打包成 CAB 檔(如圖 3-4-3)，十分方便，開啟網頁後，按下
載入檔案的按鈕，網頁就會去呼叫CAB 檔中的 OCX 檔，OCX 算是比較
外層的程式，因為我們在原始碼(source code)裡所做的更改只會更改到 OCX 檔，而一些被 OCX 檔使用到的函數已經編譯成 DLL 檔，DLL 檔這 部份的原始碼並沒有公開，所以我們無法看到當然也無法修改，我們只能 就IFCEngine DLL&OCX 所提供的功能加以應用，若真的要深入底層只能
聯絡作者，付費就能得到原始碼。DLL 檔裡的內容大致是對 IFC 格式的解
碼(parse)。IFC Engine DLL&OCX 運作原理如圖 3-4-1。
3.5 CGI 說明
CGI 全名 Common Gateway Interface 一般中譯為共用閘道介面，是 介於客戶端(Client)和伺服器端(Server)的一種通訊介面，客戶端可透過此
介面將資料傳到伺服器端，撰寫 CGI 的程式語言有很多，其中 C 與 Perl
程式語言較常用來撰寫，而 CGI 的運作原理如圖 3-5-1 所示，客戶端透
過網頁中的表格(form)形式填入資料，再由 get 或 post 機制傳遞參數給在 伺服器端的 CGI 程式，用 get 機制或用 post 機制並不是由客戶端的使用
者決定的，而是由伺服器端的管理者寫在網頁中的，而伺服器端的 CGI
程式就是我們一般的 C 語言程式，只是我們不編譯(compile)成執行檔
(.exe)而是編譯成 CGI 檔(.cgi)，這邊我們所使用來架設網頁伺服器的軟體 是Apache http server，這是一個免費且好用的軟體，所以使用率很高，
連接到網址後面，如圖 3-5-1 所示，這不僅沒有隱私且這方法只能傳有限
長度的資料，一旦資料量增多，可能會無法傳遞資料，而 post 傳遞機制
中輸入的值會被當做是 Standard_input 也就是當成外在輸入，我們可以 在程式中去抓取，不過不論是 get 機制或 post 機制，傳遞過來的資料都 是以變數名稱 A=值A&變數名稱 B=值B&…，所我們必須一個個變數去作 分析(parse)的動作，將所需的值濾出來作為程式的 input，而字串分析這 麻煩的動作已經有很多熱心的人寫好程式給我們用了，所以我們不用額外 費心自己去撰寫，這類程式網路上已經有很多可以下載，而我用的是網路 上找到的util.c 這個 C 程式來幫我做解析。
第四章 系統實作與開發
本章將說明實作系統的過程，先用JSP 動態網頁技術實作檔案上傳的
功能。再改寫IFC Engine DLL&OCX 的原始碼，以新增一些功能，讓使 用起來更便利。再以IFC 檔案開啟程式 IFCQuickBrowser 來幫助分析 IFC
檔案格式，並依據 IFC 格式撰寫一個產生柱筋 IFC 圖檔的程式，並將該
程式以CGI 的技術應用於網頁。最後利用 IFC Engine DLL&OCX 內的 API
來擷取IFC 檔案內物件的資料，擷取這些資料與規範比對進行審核。
4.1 檔案上傳系統
檔案上傳系統流程如圖 4-1-1 所示，於上傳頁面(index.htm)運用 javascript 語法來限制只能選擇副檔名為.ifc 的檔案上傳，並以訊息視窗來 警告使用者(如圖 4-1-2)，以免系統讀入不符的檔案造成毀損或當機，再 來架設資料庫系統，使用的資料庫軟體為 Microsoft Office ACCESS 2003，並以網頁伺服器架設軟體 Tomcat HTTP Server 來搭配動態網頁技 術JSP(Java Server Pages)，JSP 文件主要是以 Java 語言來開發，為提 供網頁應用程式發展的語法，負責網頁與網頁間參數的傳遞，還有網頁與 資料庫間的溝通，來達成對資料庫中資料的存取或變更等等，這邊使用的 Tomcat HTTP Server 為 Tomcat 4.1，Java SDK 的板本為 6.0，並使用 Advantys 公司所撰寫的檔案上傳的元件 jspSmartUpload，來幫助我們實 作上傳的機制，此元件是免費的，使用時需要將它包含(include)進來，語 法為<%@ page import="com.jspsmart.upload.*" %>，這樣一來我們就能 建立SmartUpload 類別的物件，以此物件來使用 SmartUpload 類別所提 供的上傳相關函數。在此用到的函數有:
initialize(pageContext) 初始化上傳或下載的相關工作 upload(); 依照指定檔案進行上傳的動作 save(path) 將上傳的檔案儲存到指定路徑，並回傳成功儲存的檔案數 getFiles() 取得上傳檔案的集合物件(Files)，以獲取更別檔案的資訊 getFileName() 取得上傳檔案的檔案名稱 檔案上傳後，將會存放到指定路徑下的資料夾，本程式的指定路徑為 Apache HTTP Server 中的資料夾，並且在資料庫 ACCESS 裡紀錄上傳 檔案的檔名，若順利儲存完成，網頁則顯示上傳成功，並有功能項目的超 連結引導使用者往下一個功能，而本研究中只針對了檢核功能做實作。詳 細內部運作流程如圖 4-1-3 所示。 進入了檢核頁面，而這頁面就是原本IFCEngine OCX&DLL 應用的頁 面，我們運用JSP 語法將讀入檔案的路徑(也就是變數“filename＂的值) 改成網頁伺服器Apache HTTP Server 的路徑，並自動從資料庫裡擷取剛 上傳檔案的檔名附於路徑後面，這樣一來就能將剛上傳的檔案讀入進行 3D 瀏覽與規範檢核了。
4.2 IFC 格式分析與資料擷取
IFC 的內容原始碼，我們用記事本或 WordPad 等文字編輯器開啟 IFC 檔時就會看到這樣一大串密密麻麻的原始碼，圖 4-2-1 所示，乍看之下很 凌亂，但是這些碼是有規則有涵義的，每一行的表示方式都是“#Number = EntityName(Attribute1, Attribure2,…); ＂，當Entity 要參考另一個 Entity 時就是靠著前面的#Number 來參照，但是這樣照順序排列很難看出 Entity 與 Entity 之間的相互關係，所以用軟體 IFCQuickBrowser 來輔助我們閱
node)和父節點(parent node)，表 4-2-1 是一段 IFC 的原始碼，這段 IFC 原始碼是一段描述柱(column)的原始碼，以 IFCQuickBrowser 開啟 IFC
檔並找到 IFCCOLUMN 點選展開就會如圖 4-2-2 所示，可以看出是以
IFCCOLUMN 為樹根(root)向下擴展的一個樹狀結構(如圖 4-2-3)，這根柱
的一些屬性就會記錄在這樹狀結構中。再看看表 4-2-2 對 IFCCOLUMN
的 定 義 ， 對 照 表 4-2-1 的 #83 內 容 ， 屬 性 GlobalId 的 內 容 就 是 字 串 ’2OCKxkKIP618ocbVxgfG$$’ ， 屬 性 OwnerHistory 的 內 容 為 #13( IFCOWNERHISTORY)，屬性 Name 的內容為字串’CRE – 001’，屬 性Description 的內容為$表示為空值(NULL)，屬性 ObjectType 的內容也 為 $ 表 示 空 值 ， 屬 性 ObjectPlacement 的 內 容 為 #132(IFCLOCALPLACEMENT) ， 屬 性 Representation 的 內 容 為 #124(IFCPRODUCTDEFINITIONSHAPE)，而屬性 Tag 的內容也為空 值，當屬性的內容須參考下一個Entity 時，我們必須一直參考下去，直到 最後有實值的部份，這實值可能為字串(String)、實數(Real)、列舉(Enum) 等等，而OPTIONAL 的意思則表示為此屬性內容可以不存在也就是空值。
在 IFCEngine 中會給每行的 Entity 一組 id，所以我們只要知道該行 Entity 的 id，就可用函數 sdaiGetStringAttrBN (id,attribution)就可擷取出
該行Entity 的任何屬性質。以此類推，依此方法我們就可以了解整個 IFC 檔的內容與屬性資料的擷取。
4.3 柱筋 IFC 檔產生器
這是一個用C 語言所撰寫的程式，來產生有鋼筋實體的 IFC 檔，目前 業界的鋼筋圖是用AutoCAD 軟體所繪製，僅用線段及標注來表示鋼筋的 資訊，鋼筋圖中僅呈現鋼筋整體之某個截面的情形(如圖 4-3-3)，用標注標示這斷面有幾根幾號的鋼筋(如圖 4-3-4)，有些還得看兩三張鋼筋圖才 能知道整個鋼筋分布的全貌，這種 2D 的鋼筋圖我們很難想像它的 3D 實 際形狀是長的怎樣，既使匯出成 IFC 格式，由於圖中的鋼筋不是以 IFC 的語法來描述，我們在IFC 3D viewer 中看到的也只會是一些線段甚至無 法匯出成 IFC 格式，在 BIM 的應用下，是無法以標注或注釋的方式來表 示物件的資訊，而是以屬性的方式儲存在物件本身中，目前的 CAD 建築 繪圖軟體都沒有使用到IFC 對鋼筋所定義的格式，有的甚至連畫鋼筋的元 件都沒有，但是IFC 的資訊架構中(如圖 4-3-11)，有預留與鋼筋連接的部 份 ， 所 以 本 研 究 參 考 IFC 的 規 格 與 IFC 定 義 鋼 筋 的 實 體 格 式 IFCReinforcingBar，寫了一個簡易的程式，先拿現有的柱子 IFC 檔案， 在該檔案中加入鋼筋的實體 IFCReinforcingBar，並填入鋼筋屬性，再用 IFCRELAGGREGATES 這個 Entity 來連接原來柱子(IFCCOLUMN)與剛 設計的鋼筋(IFCREINFORCINGBAR)，使柱與鋼筋產生關係(如圖 4-3-12 所示)。 程式設計成可以讓使用者輸入柱子與柱筋的一些參數，會產生一個矩 形柱內嵌柱筋且符合IFC 規格的圖檔，產生出來的 IFC 檔如圖 4-3-13 所 示，我們就可將這個矩形柱內嵌柱筋檔案給規範檢核程式讀入，並做一些 柱筋的規範審核，看看有沒有不符合規範的地方。 IFCReinforcingBar 是一個描述鋼筋的 Entity，除了與梁、柱相同的基 本 屬 性 外 ， 此 Entity 還 有 SteelGrade 、 NominalDiameter 、 CrossSectionArea、BarLength、BarRole、BarSurface 這些鋼筋屬性， 分別代表鋼筋等級、鋼筋斷面直徑、鋼筋斷面積、鋼筋長度、鋼筋種類、 鋼筋表面種類，其中鋼筋種類(BarRole)與鋼筋表面種類(BarSurface)是列 舉(Enumeration)型態(如圖 4-3-5 與圖 4-3-6)，我們設計的鋼筋種類只能
種類也是一樣。 鋼筋產生器之原始碼(rbar.c)編譯後以執行檔(rbar.exe)的形式執行時 如圖 4-3-7 所示。輸入的矩型柱資料有柱斷面長度、寬度及柱高度，主筋 資料有主筋數、主筋號數與主筋長度，繫筋資料有繫筋號數、縱向繫筋數 及橫向繫筋數，其他輸入資料有橫向鋼筋間距、彎鉤延伸長度與保護層厚 度。這邊我們限制主筋數目只能是偶數根，因為主筋數目若是奇數根就會 有偏心的情況，為了避免偏心的產生所以簡化設計，對使用者設計主筋數 目做出限制。另外程式只限定設計出矩形柱，且無法畫出柱筋搭接的情 況，也是為了簡化設計，方便程式的撰寫，因為將來的建築 CAD 繪圖軟 體會有符合IFC 格式的鋼筋繪圖元件，並且會有更多的功能，所以之後的
IFC 應用開發者就可直接用 CAD 繪圖軟體來繪製鋼筋圖並匯出成 IFC 檔
來做應用，目前已有某些 CAD 繪圖分析軟體已經可以設計鋼筋搭接的部
份了。
而系統在架構中，為了與網路結合，方便在網頁中執行，使用了CGI
技術，編譯過程如圖 4-3-1 所示，將鋼筋產生器原始碼(rbar.c)編譯成物 件檔(rbar.obj)，另外用來幫助解析(parse)輸入資料的 util.c 也編譯成物件 檔(util.obj)，再將這兩者連結(link)成一個 CGI 檔(rbar.cgi)，之後撰寫一個 表格(form)網頁在 rbar.html，來接收使用者所設計的參數，將輸入的參數 傳到rbar.cgi 執行，產生所設計的 IFC 檔，參數傳遞過程如圖 4-3-2 所示。 編譯環境是於 VC++命令列(command line)下編譯，編譯指令為”cl”(如圖 4-3-8、圖 4-3-9、圖 4-3-10 所示)。
4.4 IFC Engine DLL&OCX 新增功能
以作為參考加以延伸的開發下去，新增或修改原有的功能，以符合本系統 所需要的功能，而新增檢核的功能將留在4.5 與 4.6 做說明。 新增功能方面有擷取新的屬性，梁柱方面我們針對矩形斷面的梁柱擷 取了斷面長度與寬度、梁柱長度與兩端斷面的中心座標(如圖 4-4-1、圖 4-4-2)。鋼筋方面我們擷取了鋼筋等級、斷面直徑、斷面積、鋼筋長度、 鋼筋種類(主筋、箍筋、繫筋等等)、鋼筋表面形狀(竹節等等)與兩端斷面 的圓心座標(如圖 4-4-3)。樓板方面我們擷取樓板面積、樓板厚度及樓板 四個角點的座標(如圖 4-4-4)。 此外在3D 瀏覽的功能方面，我們新增了隱藏物件(hide)的功能(如圖 4-4-5)與顯示全部物件(display)的功能(如圖 4-4-6)，這方便我們將不想看 到或有礙於觀察的物件隱藏起來，並且提供恢復的功能，增加操作的靈活 度與便利性。 而在物件雙擊(double click)方面，為了使點選的物件方便觀察，我們 將被點選的物件塗上亮黃色(如圖 4-4-7)作為記號，以凸顯此物件是正被 點選的。
4.5 梁柱板構件檢核之功能
本節說明如何實作對梁柱板做空間分佈的檢核，所用的 3D 模型都是 用ArchiCAD v.11 繪圖軟體所建，並輸出成 IFC 檔案格式，檢核的項目包 括: 大梁跨小梁、梁身超過柱、兩根梁跨柱不在同一直線上與樓板開口不 良造成剪力無法傳遞。檢核後若有錯誤，會將有問題的物件塗成紅色，並 在右方顯示錯誤( Warning )的數目及對錯誤物件的描述(Description)。 大梁跨小梁 大梁跨小梁是一錯誤的情況，樓板承受載重，會將力傳遞給小梁，小 梁再傳遞給大梁，大梁再傳給柱子，一旦發生大梁跨小梁的情形，小梁承 受的力將無法傳到大梁只好承受下來，這時萬一受力超過負荷，小梁就會 發生破壞，整個結構體也會遭受影響。大梁跨小梁的例子如圖 4-5-1。 檢核時，我們先擷取出梁的端點座標，判斷哪些端點是梁與梁的相接 之處，在梁相接處的兩個端點座標，再比較兩者的斷面積，大者為大梁， 小者為小梁，若小梁的垂直向座標(z 座標)比大梁的垂直向座標來的小， 則判斷為設計錯誤，因為發生了大梁跨小梁的情況。 梁身超過柱 梁身超過柱也是一種不好的設計，如圖 4-5-2 所示，梁身超過柱的話 梁會有一部分懸空，梁傳遞受力到柱就會有一點偏心，對梁或對柱都會造 成剪力，有機會對梁或柱造成剪力破壞。 檢核時，我們先抽出梁的兩端點座標與柱與梁相接的端點座標，計算 出梁兩端點連線的空間直線方程式，再計算柱端點座標到此直線的距離， 此距離平方減去一半梁高的平方，將最後的值開根號，此值若大於柱寬的 一半則判斷為梁身超過柱。 梁跨柱不在同一直線上 這是情形是兩支梁接在同一根柱上，但是這兩支梁不在同一直線上， 如圖 4-5-3 所示，這是一個有待商榷的情況，所以我們要把這情況挑出來。 檢核時，先判斷任兩根梁是否有接在同一根柱上，抽出梁的兩端點座 標後計算兩端點所形成的向量，若兩梁的向量夾角不是 0 度或 180 度則 判斷為不在同一直線上。
樓板開口不良造成剪力無法傳遞 在樓板方面，有時可能會因為管線通道或電梯間等等因素要去掉幾塊 樓板，如圖 4-5-4 所示，若有水平向的力可能會造成樓板較少的那一列對 剪力的傳遞不良，造成破壞。這是作結構外審時可能會被檢驗的地方，若 有這情形會被挑出來要求解釋說明或重新設計。
4.6 柱筋相關規範與檢核之功能
本節說明如何實作對柱筋作檢核，所依據的規範內容均是參考「[土木 401-96]混凝土工程設計規範與解說」一書。主要是針對「RC 柱構件」的 規範。程式中也是以紅色作為警示，來表示有錯誤的物件，並在右方顯示 警告錯誤的數目(Warning)及對錯誤物件的描述( Description )，若使用者 對規範有疑慮，可點選檢核項目右邊的規範超連結，將會跳出新視窗來說 明這條檢核所依據的規範內容。 4.6.1 檢核一: 柱筋之鋼筋比 檢核時，以sdaiGetStringAttrBN (id,BarRole)=”.MAIN.”擷取出任意一 主筋之 id，再以 sdaiGetStringAttrBN (id,CrossSectionArea)擷取出該主 筋的斷面積，再計算主筋的數目是以所有鋼筋id 帶入 sdaiGetStringAttrBN (id,BarRole)，如果值是”.MAIN.”則判斷為主筋，之後再擷取出柱之斷面的 長度與寬度，而鋼筋比就等於鋼筋斷面積乘鋼筋數目再除以柱之斷面積，看是否介於規範的0.01 與 0.06 之間，這就是鋼筋比的審核。詳細規範內
4.6.2 檢核二: 相鄰箍筋與繫筋之最大間距 檢核時，我們先將箍筋與繫筋分成平行柱寬與平行柱長兩部份，先做 平行柱寬的部份，從所有的鋼筋中選出箍筋與繫筋且平行柱寬，並將它們 存入一個陣列中，寫兩個迴圈計算出每一根鋼筋與其鄰近的鋼筋之距離， 因為相鄰之鋼筋最多兩根最少一根，所以我們選兩者之大者為最大之間 距，比較所有鋼筋與相鄰鋼筋之最大間距，傳回最大值，這就是平行柱寬 的箍筋或繫筋與相鄰鋼筋之最大間距，同理我們可求出平行柱長的筋與或 繫筋與相鄰鋼筋之最大間距，我們再取這兩者之大者作為整個斷面相鄰箍 筋與繫筋之最大間距與規範規定的值進行比較。詳細規範內容如表 4-6-2。 4.6.3 檢核三: 橫向鋼筋之間距 檢核時，我們先從所有鋼筋中擷取出箍筋的部份，這一步我們可用鋼 筋屬性“BarRole”來辨認是不是箍筋，sdaiGetStringAttrBN (id,BarRole) =”.RING.”則判斷為箍筋，再計算出所有箍筋的間距，取最大的除以箍筋數 減一，值就是相鄰箍筋的間距，也就是我們所要求的橫向鋼筋的間距。而 限制條件中構材斷面可從柱的屬性來抽取，比較長度與寬度小者為構材斷 面最小尺寸。主筋直徑的取得要先挑出主筋，也就是取鋼筋屬性“BarRole” 為MAIN 的鋼筋，sdaiGetStringAttrBN (id,BarRole) =”.MAIN.”，再抽出主 筋直徑值，sdaiGetStringAttrBN (id,NominalDiameter)。而 hx可由檢核二
中求得。比較橫向鋼筋間距與三個限制式，看是否都不超過，以檢核橫向 鋼筋是否符合規範。詳細規範內容如表 4-6-3。
檢核時，我們先從所有鋼筋中挑出繫筋與箍筋，sdaiGetStringAttrBN (id,BarRole) =”LIGATURE” 或 ”.RING.” ， 再 擷 取 出 該 鋼 筋 直 徑 ， sdaiGetStringAttrBN (id,NominalDiameter)，當然直徑大於 D25 是一定不 符合規範的，之後再依彎鉤的走向向量(extruded vector)判斷出彎鉤的角 度，並擷取出彎鉤的長度這就是我們要求的彎鉤延伸長度，再判斷該彎鉤 所適用的規範來檢核。詳細規範內容如表 4-6-4。 4.6.5 檢核五: 保護層厚度 檢核時，我們要算出保護層的厚度，我們擷取出柱的寬度，再計算出 於柱寬方向相距最遠的主筋間距，並抽出主筋直徑與箍筋直徑，這時保護 層厚度的計算就等於柱寬減去主筋最大間距再減去兩倍箍筋直徑與一倍 主筋直徑，再將值除以二就是保護層厚度，為簡化檢核，我們設定保護層 厚度需不小於40mm，一旦小於 40mm，就視為不符規範。表 4-6-5。 4.6.6 檢核六: 柱筋之搭接 鋼筋的搭接在柱筋產生器裡並沒有實作出來，而是以一根鋼筋到底的 方式來繪製，由於時間的限制加上目前已經有建築 CAD 軟體可以畫出鋼 筋搭接的情形，所以就不著重在鋼筋搭接的部份，只提供搭接部份的規範 供參考，並不提供檢核。表 4-6-6。
第五章 系統展示
章節一開始將展示本研究所實作的系統，也就是網頁的架構。並以設 計好的案例模型傳入系統程式作檢核，先以建築繪圖軟體ArchiCAD 建立 梁、柱、板之模型，傳入系統程式作檢核。再以開發的柱筋產生器產生矩 形柱內嵌鋼筋的模型，傳入系統程式作檢核，並展示檢核的結果。5.1 網頁架構展示
本系統分四個部份的網頁(如圖 5-1-1)，分別是首頁(index.html)，用 來上傳檔案。柱筋設計的表格網頁(rbar.html)，用來填入設計參數。伺服 端的CGI 程式(rbar.cgi)回傳所產生 IFC 檔案。檢核頁面(check.jsp)，對柱 筋與梁、柱、板做簡單的審核。 第一部分首頁(index.html)是一個檔案上傳的系統(如圖 5-1-2)，按瀏 覽鈕可以選擇所要上傳的檔案(如圖 5-1-3)，由於是針對 IFC 檔案來實 作，所以系統限制只能上傳副檔名為.ifc 的檔案，這是利用 JSP 撰寫的動 態網頁，這部份實作了類似e-submission 的上傳檔案功能。 第二部份是鋼筋設計的表格網頁(rbar.html 如圖 5-1-4)，這頁是由首 頁超連結(hyperlink)過來的，輸入的柱資料有柱斷面長度、寬度及柱高度， 主筋資料有主筋數、主筋號數與主筋長度，繫筋資料有繫筋號數、縱向繫 筋數及橫向繫筋數，其他輸入資料有橫向鋼筋間距、彎鉤延伸長度與保護 層厚度。並有鋼筋橫斷面圖片及鋼筋標準尺寸表可引導使用者設計出想要 的柱筋設計圖。 第三部份是柱筋設計好按送出(submit)，設計資料送至伺服端後，執行CGI 程式(rbar.cgi)，回傳所產生 IFC 檔案(rbar.ifc)的超連結於頁面，供 使用者下載剛剛設計的柱筋IFC 檔(如圖 5-1-5)。 第四部份是上傳檔案後所到的檢核頁面(check.jsp) ，這頁是本研究的 核心所在，使用者可將設計好的柱筋IFC 檔案上傳至檢核頁面，進行 3D 模型瀏覽展示(如圖 5-1-6)，並透過柱半透明化來觀察柱內部的鋼筋分布 (如圖 5-1-7)，雙擊(double click)柱或鋼筋物件來檢視其基本屬性，看看 與理想的設計是否一致，並可對設計的柱筋進行規範的檢核。如果我們上 傳了有梁、柱或板的圖檔，則可以檢核梁、柱與板之空間分布不合理的情 況，這部份實作了部份的類似CORENET e-plan check 的自動規範審核 系統。
![表 4-6-5 鋼筋保護層之規定[18] 規範之 13.6.1 鋼筋之保護層(單位:mm，d b 為鋼筋或鋼線之標稱直徑) 狀 況 板、牆、閣 柵及牆板 梁、柱 及基腳 薄殼及 摺板 不受風雨侵襲且不與土壤接觸者： 鋼線或 d b ≤ 16mm 鋼筋 20 40 15 16mm<d b ≤ 36mm 鋼筋 20 40 20 D b >36mm 鋼筋 40 40 20 受風雨侵襲或與土壤接觸者： 鋼線或 d b ≤ 16mm 鋼筋 40 4](https://thumb-ap.123doks.com/thumbv2/9libinfo/8458232.183051/62.892.160.769.179.718/規範之稱直徑況板牆閣牆板及基薄殼及摺板不受鋼筋壤接鋼線或.webp)
![圖 2-3-3 自動規範審核流程示意圖[17]](https://thumb-ap.123doks.com/thumbv2/9libinfo/8458232.183051/65.892.144.777.550.879/圖233自動規範審核流程示意圖17.webp)
