第三章 國內現況調查與剖析
第二節 國內一般建築管理作業流程與特性剖析
前述圖 2-35：新北市建照、雜照、拆照、變更設計協審審查作業流程圖，
是新北市府建管行政的標準作業程序，以新北市原為臺北縣的政府體制之背景 來看，此標準作業程序應該比臺北市府的作業程序較接近全國其它縣市的建管 作業程序，因此，本文即以作業流程進行其特性探討與剖析。
壹、 建築執照掛號作業
目前全國各縣市政府的案件掛號多採單一窗口掛號方式辦理，方便民眾僅 需在單一窗口辦妥行政受理程序。由於 11 樓以下建築執照申請案，需委外協 審，協審單位每日 4 次向工務局取件，故申請人及設計建築師等，可於掛號 2 至 4 小時後，聯絡協審單位洽詢排審時間，或待協審單位於掛件(1 個工作日內) 完成排審作業後進行電話通知。掛號作業需在完成掛號預審表查填後，即應填 寫「掛號分類單」，才算受理收件掛號。
圖 3-9 新北市建築執照掛號作業流程圖 (資料來源：新北市政府工務局，2012)
貳、 排審作業
排審作業應是整個請照作業中最關鍵的部分，由於案件規模與複雜度的差 異性很大，多數一般性的案件應該在標準流程中都可在預定時程內完成，此部 分也是較耗人力的地方，從流程圖可知，掛號後協審與平行會審係同時進行，
可節省許多時間。碰到山坡地，勢必需到現場勘查，是時間上較難縮減的地方。
圖 3-10 新北市建築執照排審作業流程圖 (資料來源：新北市政府工務局，2012)
參、 校對副本及領照
案件若不通過，包括退件、補正、因未檢附土地權利證明文件或逾期 3 個 月未完成繳規費而遭駁回等，皆須要一些行政作業手續。
准照部分亦需經過核對副本與辦理套繪等幾個耗時的作業，至於繕打通知 公文及繳交規費、執照列印、校對、蓋關防等，似乎在無紙化作業流程規劃時 可以重新檢討做法。
圖 3-11 新北市建築執照校對副本及領照作業流程圖 (資料來源：新北市政府工務局，2012)
肆、 抽查
在標準流程中，抽查作業係在發照室領照之後，抽查作業的案件密度會是 整體請照審查效率的關鍵，案件抽查密度的決定機制很重要，因為密度高，自 然增加整個審查時程，所以降低抽查密度也是值得討論的一個環節。
由流程圖中可知，進到抽查作業，需再增加 5 天的作業時間，流程上亦較 繁複。
圖 3-12 新北市建築執照抽查作業流程圖 (資料來源：新北市政府工務局，2012)
由上述簡要的流程探討，雖各階段都訂定有時程上限，但相信不同的案件 規模與不同的案件複雜度，所需的時程都會不一樣，這一部分即可能產生人為 可操控的部分，假設降低人為操控部分的案件數愈多，整體審照作業效率應該 可大幅提升。本研究訪查宜蘭縣政府與委外協審單位發現，在 2012 年該縣實 施快速發照的特別措施，當然，宜蘭縣案件數較少，案件本身規模平均偏小，
情況不能等同新北市，不過，這種試圖從作業流程一開始就先將案件的規模與 複雜度做分級，而以不同的時程規範它，其實就是前述降低人為操控部分的作 為，仍值得借鏡。
圖 3-13 宜蘭縣建築執照三日發照協審作業流程圖
(資料來源：宜蘭縣政府，2013)
第三節 與建築管理作業特色相關之 BIM 應用法規面探討
COBIM 亦尚未納入自動化法規檢測，甚至美國最值得關注的 FIATECH Autocodes Project 步步為營的做法來看，以 BIM 為基礎的自動化建築法規檢測，在推動 上的限制量體外，以 spell-checking 的概念設計一些適宜的法規自動檢測小 工具附加在塑模軟體工具上，協助建築師在創建模型時，隨時提醒元件使用或 空間即時檢討，使不逾規範，讓建築設計過程更流暢，這也是 3D 的 BIM 智慧 式建模可以辦到的。BIM 技術除了可以發展直接協助法規檢測外，間接的方向亦頗有可為，例
如將多如牛毛的法規整理成更具智慧的查詢工具，讓建築師能更直覺的方式達 到順手拈來的地步，這部分在技術層面較易克服，但在匯集資訊並能保持動態 同步上，恐怕非政府出面主導不可。
在探討法規檢測自動化的同時，務必不能忽略法規本身是活性的，是動態 的問題，這部分應該是較不易掌握的，而且它也可能是整體系統架構取向的決 定因素，非常重要。
第四章 以 BIM 為基礎之自動化建築法規檢測技術的探討
Foundation Classes，產業基礎類別庫)[40]，這個已經通過 ISO 16739:2013 國際認證的標準。由於所有蒐集到跟自動化建築法規檢測技術有關的文獻，全性功能的檔案交換格式，可以支援整合型的應用程式開發。一開始並未開放其 他成員加盟，到了 1997 年，將組織名稱改為 International Alliance for Interoperability(交互操作性國際聯盟)，也重新改變聯盟發展方向與角色， 易百分百的實現，因此，所謂的 The useful minimum(有用性的最小化)[44]
的倡議開始抬頭，用 IDM(Information Delivery Manuals，資訊交付手冊)、
IFC、IFD(International Framework for Dictionaries，國際框架字典)的鐵 三角(如圖 4-1) [45]，徹底從交換需求的(ER)定義開始，將各專業領域的 Concepts(暫譯為概念元)依需求組構功能部件(Functional Parts)(如圖 4-2)，
來建構交換資訊的交付手冊與交換雙方映對的模型視域定義，(如圖 4-3 及圖 4-4)[46]，提供軟體供應商或系統開發廠商實作。同時聯盟也在 2005 年再把 名稱變更為現在的 buildingSMART，此期間，IFC 標準也從 1.0 版逐年擴充與 調整，並從 2x2 版、2x3 版，到 2012 年的 IFC4 版，新版已考慮和 GIS 的宏觀 資訊需求做銜接。
圖 4-1 IDM、IFC、IFD 的關係圖
(資料來源：Håvard Bell, Lars Bjørkhaug, Aleksander Bjaaland, Roger Grant，2008，IFD Library White Paper，[47])
圖 4-2 PM、ER、FP、與 Concepts 間的關係
(資料來源：Jeff Wix，2010，’Information Delivery Manual Guide to
Components and Development Methods’[45])
圖 4-3 IDM/MVD 整體概觀
(資料來源：Deke Smith,，2007，’Making BIM Interoperability a Reality: Technical Details of the Nationl BIM Standard’[46])
圖 4-4 IDM 的基本架構
(資料來源：Deke Smith,，2007，’Making BIM Interoperability a
Reality: Technical Details of the Nationl BIM
Standard’[46])
貳、 引進 IFC 的抉擇
(二)國際間以 IFC 為基底的模型檢測研發案例佔多數：Navisworks 是 Autodesk 旗下做模型碰撞檢測及 4D 模擬的軟體，雖然也有可能像 Solibri 軟體一 樣從原先的模型碰撞檢測技術領域跨到法規檢測的領域來。但若仔細去剖
析，除非 Autodesk 將 Navisworks 的 API，在系統內部功能方面做更大幅 度的開放(目前就有不少限制)，其可能性還是不大，何況，一個大前提必 須滿足，就是其他廠商的模型檔案都必須能匯出 Navisworks 的檔案格式，
這是否有違我國採購法，值得商榷。盡量採取與國際間以 BIM 為基礎之自 動化建築法規檢測技術的主流方向來發展，經驗的借鏡與技術的移植或參 考，在資源取得上都較優勢，尤其重要的一項已知的必要條件，就是各家 軟體工具都宣稱能匯出 IFC 格式的實作模型檔案，再加上幾家國內常見的 工具軟體，如 Revit、Microstation、ArchiCAD 等，都已經有配合外接繫 結資料標準(如 COBie)而研發 Add-in 之樣板檔的先例，所以，在這幾個必 要條件配合下，以 IFC 作為研發檢測系統的資訊模型底層格式，似乎又添 一項有利條件，值得參考。
參、 對 IFC 實作模型資料的初步掌握
本研究在進行過程中，花了相當多的時間在確認 IFC 標準於自動化建築法 規檢測的必要性與角色，從 buildingSMART 在網站所公布的 IFC 2x3 及 IFC4 的內容、STEP Part 11 及 Part 21 的規範標準去深入了解，再從幾個 IFC 相 關模型資訊瀏覽器(例如 ifcviewer、XBIM toolkits、XbimXplore、FZKViewer、
IfcObjCounter、IfcWalkTru、IfcSoreyView、IFC Quick Browser、IFCBrowser 等)，試圖了解 ifc 格式檔案的特質，圖 4-5 即用 buildingSMART 網站所提供 免費之 ifc 瀏覽器-ifcviewer，測試 ifc 檔案架構的特性。圖 4-6 則改用 Solibri 軟體載入相同的模型檔案做比較。基本上，這兩個軟體都有將 ifc 格 式檔案繪出 3D 模型的能力，也能將幾何元件和元件資料同步繫接的能力，
Solibri 還有更多的功能，在此不多做贅述。
圖 4-5 用 ifcviewer 操作一 Revit 匯出之 ifc 格式檔 (資料來源：研究小組自繪)
圖 4-6 用 Solibri 操作同一 Revit 匯出之 ifc 格式檔
(資料來源：研究小組自繪)
本研究在詳細剖析 ifc 的資料結構後，亦初步嘗試用 VS.net 平台開發一 簡易的 ifc 格式資料瀏覽與搜尋工具，取名為 IFC_Reader，採 C#語言，將.ifc 格式檔讀入後，依 Part 21 對 ifc 實作格式的語法規定，分別將元件所有屬性 資料存入 SQL Server 資料庫，並寫一瀏覽介面作呈現，如圖 4-7 所示。
圖 4-7 用 IFC_Reader 操作同一 Revit 匯出之 ifc 格式檔 (資料來源：研究小組自繪)
IFC 實作(Instance)檔案(即所謂 SPF (STEP Physical File)檔)係一文字 型態的檔案，因此檔案容量甚大，處理效率不佳，將來我國若以此格式為基底 來開發自動化建築法規檢測系統時，應考慮仿效 Solibri 公司所研發的 solibri ifc optimizer 軟體，將 ifc 資料做最佳化處裡，才能提升後續的處 理效率。
第二節 以 BIM 為基礎之自動化建築法規檢測的架構
法規檢測技術發展多年，C.Eastman[6]和三位韓國學生在 2009 年一起發 表了一篇相當經典的文章，將目前幾個主流的自動法規檢測技術做了精闢的分
類： 型的檢測而不用切換軟體。ArchiCAD 可將 Solibri 掛入即為此例。
2.設計成一套獨立的軟體，可以同時於設計過程中進行檢測。 份，它們分別是新加坡的 CORENET、挪威的 HITOS、澳洲的 Building Codes Board、
美國的 ICC 的 SmartCode、及美國 GSA 的 DAT 等。
圖 4-8 法規檢測系統應支持的四個功能類別
(資料來源：C.Eastman,2009/06/30,Automatic rule-based checking of building designs，研究小組重新繪製)
文中將新加坡(CORENET)、挪威(Statsbygg)、澳洲(CRC for CI)、美國(ICC)、
美國(GSA)五個公部門實作的檢測系統，以 A.規則解譯、B.建築模型準備、C.
規則執行、D.法規檢測報告等四大功能要素，進行比較性的剖析，這對自動化 模型檢測功能的瞭解及觀念的釐清，相當關鍵。如表 4-1 所示。
(資料來源：C.Eastman,2009/06/30,Automatic rule-based checking of building designs，再整理)
Schema, EXPRESS-XSMARTcodes builder
以下即針對這四個階段進行更詳細的說明，同時比較文件所提這五大系統 則轉化的過程中，一階謂詞邏輯(First-Order Logic)是一個可行的邏輯描述 方式，在邏輯上，「謂詞」是一個良好定義的項目(功能)，可以較容易產生明 確的需求定義，而且較容易轉換成標準的程式語法。而在處理上規則轉換主要 處理兩種要素：規則的條件與內容，及規則作用的屬性，而這些都與物件的名 稱與屬性息息相關。因此一個物件名稱與其屬性的本體是相對重要的，而 Omniclass 及 IFD 的主要工作即在此發揮很大的功能。就長遠而言，下列兩種 不同的語言發展形式可以被設想：1.謂詞邏輯基礎，經由謂詞邏輯將法規與規
(一) 新加坡的 CORENET 專案的規則解譯階段，根據 novaCITYNETS 所提供的資 料中表示，他們開發了一個語義物件(一個基於擴充 IFC 物件架構的 FORNAX 函式庫)，用以擷取建築法規所需的資訊，用以促進完成處理。其 整體架構如圖 4-9。
圖 4-9 CORENET 專案整體架構
(資料來源：Naveed Shaikh，2013，impact of code checking usage on IFC model, CAD, and end users: the challenge of imperfect data)
FORNAX 是一個物件導向且同時涉及擴充 IFC 及規則定義的部份。
CORENET 法規檢測可以區分為三個部份：(1)使用現有的 IFC 資訊進行檢 測；(2)使用擴充 IFC 的屬性集進行檢測；(3)使用從 IFC 推導出的資訊進 行檢測。CORENET 使用 FORNAX 介面及檢測模組，FORNAX 架構包含 IFC 物 件及擴充 IFC 的資訊，用以提供建築法規檢測所需的資訊。若使用 FORNAX 物件新增一條規則，程式設計師並不用真的去開發相關的演算法來擷取所 需的資料，一條規則可以用自然語言描述，經由 FORNAX 解譯成電腦可以 執行的程式(需使用其所要求的語法規範)。FORNAX 物件被定義為可以擷
取特定的規則語義，讓這個物件及它的函式可以擷取定義在規則中的屬性。
FORNAX 使用開放的 CASCADE 及 ACIS 固態核心為幾何引擎，用以取得已結 構化 IFC 建築模型的資料。CORENET 實作規則使用 FORNAX 物件所提供的
FORNAX 使用開放的 CASCADE 及 ACIS 固態核心為幾何引擎，用以取得已結 構化 IFC 建築模型的資料。CORENET 實作規則使用 FORNAX 物件所提供的