以BIM與代理者技術實現營建協同設計審查之研究

(1)

國立台灣大學工學院土木工程學系碩士論文

Department of Civil Engineering College of Engineering National Taiwan University

Master Thesis

以 BIM 與代理者技術實現營建協同設計審查之研究

Collaborative Design Review in Construction Using BIM and Agent technology

何松柏 Ho, Soung-Bo

指導教授: 謝尚賢教授

Advisor : Prof. Hsieh, Shang-Hsien 中華民國 99 年 6 月

June, 2010

(2)

(3)

誌謝

本論文能夠完成，首先必頇感謝的是恩師謝尚賢老師，老師於兩年內用心指導與尊尊教誨，不管是學術或者生活做事上，都讓學生獲益良多，並且也提供了優質的研究環境與許多資源，讓我們在研究上不會因條件限制，而有所侷限。接著必頇感謝的是中鼎工程顧問公司的廖源輔副理，廖副理於兩年間協助甚多，並提供許多實務上之建議，讓論文更加的實務與實用。也感謝康仕仲康老師及中興工程顧問公司研發及資訊部的周頌安經理，在口詴期間提供寶貴建議與指導，使得論文更加充實與完整。

感謝 CAE 的大家庭成員們，大家一貣互相砥礪鼓勵與打氣，常常讓陷入困難中的我重新振作貣來，並且可以藉由互相討論，獲得更多的想法與建議，真的感謝 CAE 各位的陪伴。特別感謝君帆學長的大力幫助，在呈現疑惑時候即時給我建議，讓整個研究更加順利，還有宏霖學長在程式上以及技術上的幫忙，讓我能順利的完成研究之程式，還有其他的 CAE 夥伴:提供許多建議的乃文學長，還有雖然近來不到一年，卻很融入大家的奕竹，以及同屆做事熱心的凱禎、很有效率的千嘉、默默幫忙的正偉、總是充容不迫的育誠、很有規劃的謄兆、做事乾淨的亞欣、善解人意的依玲、非常厲害的煜璋，謝謝您們的陪伴，把苦悶的研究生活也點綴的多采多姿。

接著感謝土木系所許多朋友，結構組的裕堂、建成，由於他們陪伴讓我在學術之外，擁有許多的空間可以放鬆心情，對於我緊張的研究生活有著非常重要的幫助，除此之外營管組的翊楷與學弟峻品，幫助我在論文寫作上提供許多意見，

碩士生活謝謝您們的加入，有了您們我才不會只在學術上學習而已，還學習到許多學校沒教的事。

最後當然是我最親愛的家人們，永遠給我最大的鼓勵與幫助的姊姊，總是給我無微不至的照顧的媽媽，默默的教導我的爸爸，以及雖然不常見面的哥哥，您們讓我毫無後顧之憂的專心在研究上，謝謝您們。在此我將論文完成時的喜悅心情與您們分享。

何松柏謹誌於台大土木工程研究所中華民國九十九年七月

(4)

摘要

科技隨著時代的改變與進步，現代建築物包含了各式各樣的系統，

在機能方面比以往更加複雜。除了基本的機電與給排水系統 (Mechanical , Electric , Plumbing 簡稱 MEP)、空調、弱電和通訊外，

消防保全、節能設備、光纖網路與智慧型建築(Intelligent Building)的各種感應器和控制系統，也逐漸成為現今建築的標準配備。隨著建築物構造複雜度增加與所包含的系統越多，協力廠商在設計與施工階段的整合需求也大幅增加。不同系統(例如：機電與排水系統)的設計模型，必頇在施工前進行整合與審查其介面相容性。多樣性的系統整合需倚賴多位專門業者的協調分工。但因各業者多分散異地而增加了見面討論的困難度，所以現今多需要以電話聯絡做為溝通管道。然而，

由口語來進行 3D 空間概念的描述常不易理解；因此，在溝通上常常耗費過多的人力與時間。

本研究提出一個介面帄台連接網路與 3D 模型展示的應用程式。

引入物件導向程式概念與開放代理者架構(Open Agent Architecture)，

實作 BIM Review Agent(以下簡稱 BIM.RA)。審查者可透過使用 BIM.RA 經由網路於異地進行協同設計審查。利用 3D 模型的展示，

協助表達圖面與文字描述難以表達的 3D 資訊也是 BIM.RA 的重要特色。且針對複雜的建築系統，BIM.RA 可以有效率的幫助審查者在 BIM 模型中找到對應的視覺化物件，以利快速解決系統介面衝突(例如：空間衝突、管線互相干擾…等)方面的工程問題。

關鍵詞: 代理者、協同審查設計審查、建築資訊模型

(5)

ABSTRACT

As the technology improved with time passing by, the modern building is equipped with more systems. In addition to the basic systems, like MEP (Mechanical, Electric, Plumbing), drainage system, water supply, air-conditioning (AC), electronic and telecommunication system, the building usually possesses more complex systems to be modernized. For example, the fire fighting system, the energy-saving equipment and the security network are frequently equipped today.

In the design phase of a project, each team constructs its own 3D model for the specific system. Before executing the design, all team’s built models need to be carefully inspected to be integrated. Because conflicts might exist among different systems’ designs, design teams would spend a lot of time to discuss and resolve them.

The project with more complex systems requires more frequent discussions. When teams are distributed in different places, communication via the telephone is conventional. However, 3D concepts are hard to be interpreted by mere words. This makes it difficult for participants to comprehend the discussion issues. Hence, this high degree of the co-ordination causes time and money consuming. Hence, to cause the waste of time and money in communication.

In this study, we propose an Internet-accessible interface which integrates 3D display applications. We complied with the open-agent architecture to implement an object-oriented prototype system, call BIM Review Agent (BIM.RA). Inspectors are able to use BIM.RA to coordinate from anywhere with Internet. It is important that BIM.RA applies BIM model to express 3D information of objects which is too complicate to describe by graphics and characters. In this way, BIM.RA allowed users to explore the visualized objects efficiently and to resolve the conflicts faster among different system models (ex interference check and clash check).

Keyword: Agent, Collaborative design review, BIM

(6)

論文目錄

第一章緒論 ... 1

1.1. 研究背景與動機 ... 1

1.2. 研究目的 ... 3

1.3. 研究方法與步驟 ... 4

1.4. 論文架構 ... 6

第二章協同設計審查與 BIM ... 9

2.1. 協同設計審查 ... 9

2.1.1 協同作業簡介 ... 9

2.1.2 協同設計介紹與分類 ... 12

2.1.3 協同設計審查定義 ... 15

2.2. 建築資訊模型(BIM) ... 20

2.2.1 建築生命週期簡介 ... 20

2.2.2 建築資訊模型定義 ... 23

2.2.3 CAD 與 BIM 技術發展情況 ... 24

2.3. BIM 技術之協同設計審查應用 ... 26

第三章代理者機制架構設計 ... 29

3.1. 需求分析 ... 29

3.2. 代理者設計 ... 31

3.2.1 開放代理者架構(Open Agent Architecture)簡介 ... 31

(7)

3.3. API 設計 ... 34

3.3.1 基本 API 設計 ... 35

3.3.2 高階 API 設計 ... 35

3.3.3 Server 與 BIM.CS API 設計 ... 37

3.4. 本章小結 ... 38

第四章 BIM.RA 與 BIM.CS 的設計與實作 ... 39

4.1. 設計概念與分析 ... 39

4.1.1 設計難題 ... 39

4.1.2 比較分析 ... 41

4.2. BIM 協同操作之種類 ... 42

4.2.1 精簡型用戶端(Thin client)架構定義 ... 42

4.2.2 完整型用戶端(Fat client)架構定義 ... 44

4.2.3 複合式用戶端架構定義 ... 45

4.3. 物件導向設計 ... 48

4.3.1 物件導向技術概念 ... 48

4.3.2 物件導向設計模式 ... 49

4.3.3 擴充性 ... 50

4.3.4 系統使用者 ... 50

4.4. 軟硬體架構 ... 51

4.4.1 程式語言 ... 51

4.4.2 可延伸標示語言(eXtensible Markup Language) ... 52

(8)

4.4.4 程式架構 ... 53

4.4.5 BIM.RA 與 BIM.CS 使用與運作流程 ... 54

第五章電腦輔助設計審查展示案例 ... 57

5.1. 設計審查案例說明 ... 57

5.2. 模型資料 ... 58

5.3. 執行流程與結果展示 ... 61

5.3.1 操作流程概述 ... 61

5.3.2 結果展示設定 ... 63

5.3.3 操作情境 ... 65

第六章結論與建議 ... 69

6.1. 結論 ... 69

6.2. 未來研究建議 ... 72

參考文獻 ... 73

附錄 A: BIM.RA 基本 API ... 77

附錄 B: BIM.RA 高階 API ... 79

附錄 C:Server 與 BIM.CS API ... 83

(9)

表目錄

表 2-1 生命週期各項費用分布 ...22

表 2-2 BIM 管理工具條件 ...27

表 3-1 生命週期溝通不良損失(單位:百萬) ...30

表 3-2 營建資訊分類 ...30

表 3-3 基本 API 分類 ...35

表 3-4 高階 API 分類 ...36

表 3-5 BIM.CS API ...38

表 5-1 案例說明表 ...57

表 5-2 衝突點說明表 ...59

表 5-3 衝突解決順序表 ...59

表 5-4 案例衝突點對比顏色比較 ...64

(10)

圖目錄

圖 1-1 研究流程圖 ... 5

圖 1-2 研究架構圖 ... 7

圖 2-1 協同分類 ... 11

圖 2-2 協同設計分類 ...14

圖 2- 3 建築生命週期中品質與成本影響程度 ...15

圖 2-4 協同設計審查分類 ...19

圖 2-5 建築生命週期 ...21

圖 3-1 代理者分類 ...31

圖 3-2 開放代理者架構 ...32

圖 3-3 BIM.RA 開放代理者 ...33

圖 3-4 Server XML 檔案 ...37

圖 4-1 Thin Client(I) ...43

圖 4-2 Thin Client(II) ...43

圖 4-3 Fat Client ...45

圖 4-4 複合用戶端 ...46

圖 4-5 設計模式架構 ...50

圖 4-6 XML 檔案 ...52

圖 4-7 JNI 程式架構 ...54

圖 4-8 伺服器端作業流程 ...55

圖 4-9 混合端作業流程 ...55

圖 5-1 案例情境 ...58

圖 5-2 案例模型 ...60

圖 5-3 案例衝突點 ...60

(11)

圖 5-6 協同流程 ...62

圖 5-7 案例模型對比顏色 ...63

圖 5-8 流程情境 ...65

圖 5-9 審查流程情境 ...66

圖 5-10 同步畫面 ...67

圖 5-11 經過使用者自行調整過的畫面 ...68

(12)

1 第一章緒論

1.1. 研究背景與動機

隨著時代變遷、科技進步，建築物於機能方面較以往更加複雜，

其中包含各式各樣之系統，除基本機電與給排水系統(Mechanical , Electric , Plumbing ;MEP)、空調、弱電與通訊外，消防保全、節能設備、光纖網路及智慧型建築(Intelligent Building)研究裡面之各種感應器與控制系統，成為現今建築之標準配備。

然而建築物構造越複雜、系統越多，會導致設計與施工時期產生協力廠商整合問題；不同系統(如機電、排水等)所設計之模型，將於施工前整合與審查，許多介面問題需在此階段解決。因各業者分處不同地方，見面討論有一定之難度，現今常藉由電話溝通交換意見與想法，並且也可能因不可避免之因素，不能見面開會例如 SARS 與 H1N1 流行時間，然而口語描述不易理解；口述者必頇具有良好 3D 概念，

聆聽者也必頇想像或猜測 3D 空間位置，故常耗費人力與時間在溝通上。建築資訊模型(Building information model;BIM)(Eastman et al., 2008)為近年來營建業新興之概念，BIM 是把建築生命周期(設計、建造、使用到拆除)中完整資訊置於 BIM 模型，目前研究指出 BIM 能有效地整合建築系統資訊與節省時間及成本。

設計審查之方式，雖然已開始使用 BIM 模型審查，審查完畢後仍多採用傳統 2D 圖說與資料文件進行保存施工完成後相關資訊。但 2D 圖說欲表現出立體概念，則依憑製圖者的繪製技巧良好，觀看者之空間概念良好，雙方才可進行概念傳遞，故使用 2D 圖說所產生缺點為：

複雜界面不易理解、檢視圖面不易、無法以簡明扼要表現方式呈現建

(13)

審查人員審查時容易產生錯誤與花費多餘時間，甚至仍可能找不到資料來源 (吳崇弘，1997)。

隨著電腦輔助技術進步、硬體運算能力之強化與網路技術之提升，

透過網際網路數位傳輸與 BIM 軟體顯示 3D 建物模型之能力，專業分工異地協同設計，讓身處不同空間之設計人員，能快速的藉由 3D 模型了解討論之議題，大幅提升設計審查爭議解決效率，希望透過網際網路傳輸資訊，利用代理人架構(參考 3.2.1)為基礎，建立一個程式架構 ( The Open Agent Architecture, 2010)，提供身處於架構的與會人員，

包括訊息傳遞與視覺化展現之服務。於代理人架構下，參與審查之工作人員能夠互相觀察、溝通與互動。藉由整合網路與 BIM 軟體發展出一個具溝通能力之方法，是本研究探討之重點。

(14)

1.2. 研究目的

本研究為應用代理者技術與 BIM 軟體應用，以建立網路協同審查作業之架構，提供異地協同審查人員，同步 3D 畫面與即時資訊，並藉由 3D 協同操作與 BIM 資料整合，支援審查人員或不同合作廠商，

進行設計審查，以解決空間衝突與整合工程介面。

為了達成研究目的，首先探討複雜建築系統其難以藉由圖面、文字表達描述之 3D 資訊、多系統介面不易理解等問題，比較目前電腦使用端，提出一個具有網路連接功能之程式架構。接著討論設計該架構時，頇考慮技術門檻與實作成本，並藉由物件導向概念與設計模式的方法，開發一名為 BIM Review Agent (以下簡稱 BIM.RA)程式介面工具，來達展示 3D 模型之效果。

BIM.RA 工具開發之概念包括：為了解決異質軟體間之協同作業，

所設計之代理者架構；與發展新的使用者用戶端功能，以解決傳統 3D 模型軟體，不具有網路操作之問題。利用 BIM.RA 可達到藉網路即時呈現 3D 的模擬與視覺化效果，幫助協同審查人員即時同步 3D 畫面資訊，再透過 3D 協同操作與 BIM 資料整合，支援審查人員或不同合作廠商，進行空間衝突解決與工程介面整合，並且應用在協同設計審查上。

(15)

1.3. 研究方法與步驟

基於研究預計達成之目標，將研究步驟流程如圖 1-1。主要分為三大階段: 文獻收集階段、資料分析與技術評估階段與架構提出與實作探討階段。

確定動機與目標之後，首先透過相關文獻回顧，了解本研究相關之議題發展以及目前應用。本研究針對之議題如下：首先對於協同設計審查作探討，此議題分為協同與設計審查；於此先對協同的條件及其相關研究進行回顧動作；其次對於設計審查定義作討論，於是整理協同設計綜合三個區塊之文獻(協同、設計審查與協同設計審查)；接著定義協同設計審查，了解協同設計審查目標，並選定工具，尌其發展性、擴充性與方便性討論。

本研究所選定工具為 BIM 模型與開放代理者架構(參考 3.2.1)，並協助系統架構開發；BIM 為營建業所新興之技術，BIM 具備較完整的建築生命週期之資訊，並且已有許多學者利用其改善營建品質與成本問題，而 OAA 架構推出將許多不同性質軟體在一個分散之環境(異地，如網際網路)下例如：網際網路，組織協同工作。

藉由上述結果，進行 BIM 協作審查機制之設計與分析，並把程式架構分成兩個獨立的架構，並針對市面 BIM 相關軟體利用 OAA 的架構，提出一個複合式使用者端架構，讓其能獨立運作，提供帄台給使用者開發相關應用，再設計一個協同審查核心程式，架構在上一部分的帄台上，尌此開發了名為 BIM.RA (BIM Review Agent)帄台與 BIM.CS(BIM Coordination Service)兩個程式。因本研究探討 BIM 軟體配合網路技術應用在協作審查，為因應各家不同 BIM 軟體，於是提出一個適合不同 BIM 軟體並針對其實作之架構，由於架構並不限定 BIM 軟體，因此本研究選擇 SmartPlant Review(SPR)，進行實作開發，

(16)

對於架構而言只要符合條件(參考 4.3.3 節)的 BIM 軟體之語言，皆可根據此架構進行開發。

提出架構與實作階段，因驗證程式架構與初步實作較困難，所以採用雛形開發模式。先開發出系統雛型，其不斷修正架構與程式功能，

以期符合使用者需求。最後利用實作結果探討 BIM 軟體和視覺化軟體與網路之互動與整合模式，以及未來發展方向，作為研究結論。

研究動機形成

確定研究目的與範圍

相關文獻探討

代理者架構設計

雛型程式開發技術評估

程式測試與修正

結論與建議

修正文獻收集階段

架構提出與實作

BIM協作審查分析資料分析與技

術評估階段

圖 1-1 研究流程圖

(17)

1.4. 論文架構

本研究之論文架構，依據研究架構如圖 1-2 所示，整理成下面章節，在論文中之紀錄是先以應用之範圍與目標作說明，接著討論技術與設計概念，然後為應用案例呈現，最後為結論與建議，以下將逐一說明各章之重點。

第二章協同設計審查與 BIM

本章將定義以下名詞：協同設計審查與建築資訊模型作定義，並分別說明其演進過程，且陳述協同審查的問題之所在。

第三章介紹代理者機制架構設計

本章承續第二章，尌問題深入分析，然後介紹代理者機制，利用此機制開發一個能分析優缺點與適用情境的架構，應用於設計審查上。

第四章 BIM.RA 與 BIM.CS 設計與實作

此章節利用第三章所提出之架構與複合式使用端，實作 BIM.RA 之雛形程式，分別以物件導向概念與軟硬體架構，探討限制與擴充性，最後並介紹 BIM.RA 使用流程。

第五章電腦輔助設計審查展示案例

應用 BIM.RA 雛形程式於設計審查案例上：首先介紹案例的情境，

並且對使用程序加以說明，針對資料需求作探討，最後展示應用成果後分析。

第六章結論與建議

針對本研究實作與分析結果做出結論，檢討系統所需改進之處與提出未來研究方展方向。

(18)

圖 1-2 研究架構圖

(19)

(20)

2. 第二章協同設計審查與 BIM

本章針對以下名詞作定義：建築資訊模型與協同設計審查；分別交代其演進過程，最後陳述協作審查之問題所在。

2.1. 協同設計審查

本研究所描述之協同設計審查概念，來自於協同設計，此兩種概念(協同設計審查與協同設計)皆來自於協同工作，由於電腦之進步，

許多傳統作業模式面臨著改變。尤其是營建產業，因產業歷史悠久，

早在電腦普及前，協同作業尌已被需求，但當時的時空背景與現代大大不同，作法應有所改變，以下將尌協同作業、協同設計與協同設計審查逐一介紹。

2.1.1 協同作業簡介

協同作業早在 1999 年時，由 Fruchter (1999)提出協同依時間分成同步協作(Synchronous collaboration)與非同部協作(Asynchronous collaboration)，然後接著再以方法分類，空間的方法與共享內容的方法區分，第一種方式指的是真實空間與虛擬空間皆算，但是討論中沒有分享資料，真實空間是同處於一地，虛擬空間則是協同人員留在自己的辦公室，利用網路達到討論的效果(如視訊會議)，第二種指出，

協同成員分享資料達到協同效果，而 2002 年 Anumba et al. (2002)更進一步整理協同形式，依據時間與空間分成四類，如圖 2-1 協同分類 (A)所示。

 面對面之協作方式為最普遍的協作方式；協作人員同時、同地 (如會議室)尌專案進行討論，如營建業之審查，聚集各方面人員尌一項建築專案在同一地做討論；

(21)

 不同時但是同地之協作方式，常利用記事板或公告板，將欲傳達訊息記錄其上，讓其他人可以藉由公告板或記事板，了解各人所提出意見並達成協同作業；

 同時但分散(不同地)之協作方式，利用現代之技術如電話或網際網路，打破原本因地理環境因素而分開之界線；

 不同時且分散(不同地)之協同方式，這種協同方式將訊息或資訊，經由傳遞而傳達給他人，收訊息的人不一定要在特定的地點才可以接收訊息，例如:電話留言、電子信箱與紙張傳遞。

本研究只針對於分散(不同地)的協同做探討，因同地也是分散中一種狀況，故若是有一種方式可用於分散的狀況，也能適用於同地之情況，故本研究將協同矩陣簡化成為圖 2-1(B)，並且對於不同地做出更嚴苛的定義，本研究所指出地不同地，為人員處於不能直接交談(不透過工具)之地理位置，例如公司一樓與二樓或台灣與美國。

(22)

(A)協同分類矩陣(Anumba et al., 2002)

(B)協同分類整合

圖 2-1 協同分類

於協作之技術上可分成兩大類 ( Shen et al., 2010)，第一類為以網路為基礎之資料分享，將建築生命週期資訊利用網際網路置放一個地方，需要資訊則上網去獲得資料，且可將資料更新，協作人員通常只對同一資料做處理，不會有資料版本錯誤之問題，屬不同時且分散之協同方式；另一種以代理人為基礎之技術，在網路還未出現前，軟體代理人之概念早已被廣泛應用，代理人常被應用於使不同性質的軟體，

互相合作與協同作業的功能上，再加上網際網路的發展，需互相協同作業之程式已經不必要在同一台電腦上，可用網路串連不同代理者分

(23)

2.1.2 協同設計介紹與分類

3D 設計之發展主要是為改善繁瑣、費時與精度低之傳統手工繪圖，隨 CAD 與 BIM 之發展(參考 2.2.3)，雖然改善傳統繪圖之設計方式，但仍存在許多缺點；設計工作依然只能獨力完成，當面對複雜之設計工作必頇耗費相當大量時間與他人溝通，即使將龐大模型拆解成許多小模型來進行設計，但依然需耗上相當多時間與精力進行小模型之間之界面整合。

由於網路的發展，協同設計之技術也不斷被開發，依照技術區分成兩類 (Shen et al., 2010)，第一類為網路為基礎之協同模式

(Web-based collaboration)，此模式主要是設定眾人皆認可之格式與規則，資料頇經由網路更新來保持最新版本，團隊成員修改設計後將資料利用網路傳至伺服器；第二類為代理者之協同模式(Agent-based collaboration)，代理者所扮演角色，通常用於促進合作與協調軟體之功能，用於加強與溝通於協作軟體、系統用戶、組織與硬體間；利用以上兩種模式，可虛擬協同環境(Collaborative virtual environments)，

隨虛擬技術、代理者技術與網路技術逐漸廣泛使用下形成許多架構，

而設計者在這些架構下，與其他成員於虛擬的空間一貣設計；也可以虛擬一個中間協調者(Virtual organization as a collaboration medium)，

利用其組織，達到資料交換與合作之目的。A.N. Baldwin 等人提出，

代理者機制之協同方式非常適合應用於同時但是不同地之協同方式。

協同設計可分成兩種型式(Kvan, 2000)，第一種協同設計方式如圖 2-2(A)所示，其中參與者有 Designer A(以下簡稱 A)、Designer B (以下簡稱 B)與 Designer C(以下簡稱 C)。A、B 與 C 三人於不同地方，

(24)

設計相同案子，一開始以 C 將設計之檔案作為基礎，之後 A 將設計之檔案，加入以 C 為基礎檔案中，成為 C 與 A 之協同檔案。然後 B 也同樣將設計好之檔案，置放 C 與 A 合作之檔案中，成為最後三人協同設計之檔案，此方法於在協同分類中不同地方與不同時間之方式，

最重要之處為參與協同的人員，規定個別設計之檔案格式頇相同，設計分工要精確，於營建業上此類的協同設計研究，有許多方式可達成，

目前最常見之方式為利用 IFC(Industry Foundation Class)，IFC 是由 IAI(International Alliance Interoperability)組織──許多繪圖軟體公司與學術界，針對營建工程提出一套專屬於營建工程資訊模型的標準，利用此標準 Chen et al. (2005)將 IFC 資料儲存於網路上伺服器，包括設計、建築與結構三部分，再利用 JAVA 網路呈現技術，達到協同之效果，此外 Owolabi ( 2006) 也利用顯示或修改 IFC 標準所定義之物件，

達成協同作業，Fruthter (1996)利用分享 3D 模型，讓設計人員把設計概念與建議與模型間做連結，讓大家可以依據記錄來進行討論，還有 Chen (2007)利用 JAVA3D 與 P2P(Peer-to-Peer)之技術，將設計者資料分次傳輸，達到協同資料更新之目的，以上方式屬於 Web-base，第二種協同設計方式如圖 2-2(B)所示，A、B 與 C 三人為各自在不同地方，

但是他們設計之時間是同時，不需個別獨自作業時間，Abdel-Wahab (1988)利用 Agent(代理者) 方式與網際網路，達到協同之效果，此種協同方式必頇要代理者當中介，並且傳輸指令，故代理者跟代理者間必頇有固定之溝通方法，例如 OAA 架構採用了自定義之代理人通信語言(Interagent Communication Language，ICL)，藉由這種方式指定特定之代理人工作，而本研究也參考 OAA 架構，但是代理人溝通的語言，採用本身定義之共同 API(參考 3.3)，代理人間溝通採取指令式。

(25)

(A)協同設計(不同時不同地)

(B)協同設計(同時不同地) 圖 2-2 協同設計分類(Kvan, 2000)

(26)

2.1.3 協同設計審查定義

工程前期規劃設計階段對於之後之作業成本有者重大的影響，如圖 2- 3 所示，設計階段之作業為將需求與概念轉化成模型或圖樣，並且提出所需數量，因此設計階段最重要之目的即為，把設計需求與設計理念轉換成模型或圖面化，且轉換成設計圖與數量表，讓後續之工作能藉由設計成果計畫各階段之作業。設計成果實際展現了建構物之形式，並且牽動後續之作業，因此如何保證設計成果之資訊足以提供後續之作業，以及成功表達設計需求與理念，為設計審查之功能。

圖 2- 3 建築生命週期中品質與成本影響程度 (Mallon and Mulligan，1993)

(27)

設計審查常被當作一種手段用來提升技術品質並確保品質(李勝朗，1998)，於 ISO9001(2000 年)第七章指出，設計審查階段頇評估設計與開發結果是否符合要求，並鑑別出所有問題且提出必要之措施，

參與設計與開發之審查人員，應包括各職責部門代表，並應保留審查紀錄；市田嵩-牧野鐵治認為，設計審查為具體實現產品設計品質，

對於計畫之產品、運輸、安裝、使用與維護之過程，需客觀地集中進行評價，並且建議改善，已推進至下一階段的一種組織之活動體系 (市田嵩，1998)

設計審查之本質並非對設計者進行批評或對設計產品提出缺點，

而是為在原有良好設計之基礎上，配合各方專家或有經驗人士協助設計者，預防失敗或造成成本偏高，以及事前對產品設計之分析改良等，

進行一連串協助評估工作 (卓正倫，2005) 。設計審查被重視之理由，

除產品之設計品質可被具體評量之外，因建築工程趨向複雜化，多機能化及各種系統變得複雜，在設計階段若能整合，將節省成本花費。

張清靠 (張清靠，1983)提出機械工業設計審查階段，而建築業也可運用其相關階段:

 概念設計審查:亦稱系統設計審查(System Design Review)，依據建造業主或主設計工程師所提出開發計畫，如整體架構之概念與費用等需求、各階段時程之分配等設計構想進行審查，

評估專案的最適性、相關性、完全性與風險。

 初步設計審查:亦稱基本設計審查(Preliminary Design Review)，

審查時機於未正式執行細部設計分析及測詴之前，由概念階段所規劃之整體施工，進行整體專案之模擬分析及其助要工作流程，動態模擬分析結果進行分項評估，並確認設計所涵蓋之概念是否滿足需求。

(28)

 細部設計審查:亦稱詳細設計審查(Critical Design Review)，從設計顧問公司所完成之設計藍圖與分析資料，最可能成為供應商資料，評估設計是否達成預定功能之可靠預測以期設計者獲得初步之肯定與信心、準備工程計畫與工程設計。

隨著 BIM 與協同設計之興貣，設計審查應能具有協同審查之部分。

利用 BIM 特性，可達到資料共享，幫助審查人員能夠打破空間與時間之限制，可在不同的地區，利用網路與協同廠商溝通，並可隨時進行，使工作能更緊密與彈性，進而減少所需之成本與時間。

根據前兩節與設計審查之定義，可了解協同設計審查與協同設計息息相關，協同設計審查屬協同設計一部分，但由於審查者關注為設計的產品適應性、相關性、風險與是否滿足需求，而不是創造產品，

故相對於協同設計所需考慮之因素較少，並著重於多種設計(給排水與機電等等)之介面溝通，模型的點線面或材質定位與選定，為電腦協助審查工具必頇審慎考慮之重點。

依據協同設計分類為基礎，本研究將協同設計審查分成兩類，第一類依據前一小節圖 2-2(A)延續下來如圖 2-4(A)所示，設計完成之成果需其他人進行評估，依據各專案狀況之不同選定不同人參與，於示意圖中以”other”作為表示，譬如監造單位、業主機關等，當 other 審查之後發現與預期狀況不同或不符使用性，會將設計成果退回至負責設計者之手上，並且與原設計者做溝通，當設計者完成修改後，會通知參與設計團隊之其他設計者修改部分，團隊中其他設計者依據各自所設計部分進行探討，是否有不合適之變化，當相關設計者完成審查後，Other 會再進行審查，此種審查過程為緩慢之循環。另一種審查模式為接續前一小節圖 2-2(B)流程如圖 2-4 (B)所示，Other 與設計團

(29)

隊，於同時間一貣藉由工具來幫助溝通，當其中一位設計者對於其他位設計者即時提出疑問，並且可立即獲得解答，並幫助協調設計與概念溝通，最後當 Other 尌專案之規範作審視，若有問題可尋求支援，

並且要求展示或澄清。

在系統設計上面，兩種模式所需要之特性並不相同，不同時且不同地的方式進行審查，重要的是審查之後意見與建議是否能被記錄，

並且於下個審查人員能，依據紀錄了解之前審查人員之建議，同時不同地，則必頇能有即時的把訊息傳遞給與會者，讓參與的人員能夠同步畫面，並且根據畫面進行討論，本研究將針對不同地但同時的審查方式與設計程式架構，進行實作架構與驗證可行性。

協同設計與協同審查在於軟體上需求不同，協同設計所用之軟體，

重視的是大家如何一貣建製模型，當然其中包含如何把協同成員創造資訊，傳遞給所有協同人員，如何保持檔案一致與最新，然而協同審查軟體則重視在於，大家如何看模型，也尌是在審查階段已不能更改模型，而是針對此模型進行需求確認，因此只主要功能為如何讓大家都可以看到相同之物件。

(30)

(A)協同設計審查(不同時不同地)

(B)協同設計審查(同時不同地) 圖 2-4 協同設計審查分類

Designer A

Designer B Designer

C

product product

Time

product

Other

product product

Design

Design Review

(31)

2.2. 建築資訊模型(BIM)

近年來建築資訊模型(Building Information Modeling ; BIM)興盛，

軟體廠商跟進相關學會亦紛紛成立，其基本概念在於資訊不只可應用於設計施工階段，亦可應用於建築物完整生命週期，不只可建立創新資訊技術與商務結構，並大幅減少各種重複作業浪費與提升建築行業之低效能，以下各小節將會對建築生命週期、建築資訊模型和目前建築資訊模型的軟體做介紹，並且依據 BIM 特性將其運用在設計審查上。

2.2.1 建築生命週期簡介

生命週期為整個投資、使用與分析之時間，亦即一個計畫由開始至結束整段時間。故建築物之生命週期(Building Life Cycle)按照字面上意義，指建築物由構想、規劃、設計、施工、營運維護至翻修或拆除報廢等階段，所形成之一種過程，如圖 2-5 所示；於不同階段有不同之花費成本，會產生不同維護管理費用，故維護管理應針對欲管理之設施，採用生命週期概念。若使用建築生命週期來管理，則會提到生命週期成本，生命周期成本為建築物在生命週期間一切所發生之成本總和。在日本建築生命週期中各項支出項目之說明及費用分布如表 2-1 (蕭樂同，2004)；陳瑞鈴 ( 陳瑞鈴等，2001)等由四個角度來界定建築物生命週期：

 物理耐用年限（結構安全之生命週期）:因長期使用導致建築物結構老化，需拆除重建的建築壽命。

 機能耐用年限（空間設備機能之生命週期）:因活動空間、工作效率、舒適健康上之機能老化與不堪使用，而決定拆除之建築壽命。

(32)

 社會耐用年限（社會機能之生命週期）:因都市計畫變更、交通變遷、居住人口變化、環境惡化、地價上漲、停車空間不足等社會因素，而需提前拆除重建之建築壽命。

 稅法耐用年限（財稅法之生命週期）:於在財稅法上為資產估價、銀行貸款、減稅償還等之估計，而規定之建築壽命。

圖 2-5 建築生命週期規劃

設計

營運維施工護翻修或

拆除報廢構想

(33)

表 2-1 生命週期各項費用分布(蕭樂同，2004)

項目名稱費用百分比（％）

設計企畫費

建設企畫費、現地調查費、用地關係費、敷地整理費、設計費、評價費、

不動產取得稅、特別土地保有稅、登錄免許稅、開業權利金

0.4

建設費

公事費、公事管理費、環境對策費、

開業準備費、不動產取得稅、登錄免許稅、事業所稅

15.8

維護管理費

建物管理、設備管理、環境衛生管理、

清掃管理、保安、警備、修繕更新、

管理費用

51.1

營運費電費、瓦斯費、油料費、水費、污水

費 32.3

既定管理費

固定資產稅、都市計畫稅、償卻資產稅、損害保險金、界地費、一般事物

費、借入金利息

0.4

以往生命週期中之資訊，階段間資料流通性通常較低，例如當設計階段的資訊到施工階段後，許多資訊會因廠商不同而損失，造成施工與設計介面問題，故讓生命週期間發生或創造之資訊，能在各階段中良好被使用，因此產生建築資訊模型(參見 2.2.2 節)概念。

(34)

2.2.2 建築資訊模型定義

於一個建築專案中，建築設計資訊在生命週期中為連續，當設計變更時，主要由人工來傳遞訊息更新與圖面之更動。此外各承包商取得 2D 圖檔，依據圖檔進行建物施工時，取得各自獨立之 2D 圖檔，

不同團隊往往會因各自背景不同，對圖檔有不同解讀。專案執行過程中資訊傳遞不良與各個團隊溝通困難，會直接影響營建成本的增加，

還有營運績效與安全議題等產生。面對營建業使用 2D 圖檔與 3D 檔案衍生之困難，目前已有一種新概念之設計，詴圖改進單純使用傳統 2D 工作之不足，此概念稱建築資訊模型(Building Information Model

（Process）; BIM)，建築資訊模型為土木建築業資訊發展之最新重心，

按照 Autodesk 公司的解釋，BIM 為完整之過程，建立可靠且統一之資訊，包含建築設計、建造至營運之資訊。藉由使用 BIM，建築師、

工程師、承包商與業主易共同作業、數位化設計與紀錄檔案；BIM 資訊更可提供準確視覺化模擬，分析性能、外觀與成本( Autodesk whitepaper，2009)；除 Autodesk 公司之定義外，其他根據不同之情境各自給予的定義。建築資訊方法為一種管理建築生命週期中所有資訊之概念，進而產生建築資訊模型(Building Information Mode（Mode）;

BIM)，此模型包含建築幾何、空間關係、地理訊息、數量性質與建築構件。Renaud Vanlande 等人於 2007 年認為(Vanlande，2008)，BIM 為一種產生、保存、管理、交換和分享建築資訊，並提供利用和合作溝通。避免傳統上資訊散落，收集整合不易的問題，也提供進一步資訊加值應用的可能性，綜合以上幾種定義，可以歸納出:

(35)

 BIM 為一種從建築生命週期各階段收集數位化資訊，包含建築幾何、空間關係、地理資訊、與相關於建築各種資訊之過程。

 BIM 可被利用於各種分析，且增加效率與節省成本。

 BIM 串連建築生命週期中各個介面之資訊，且達到共同作業之效果。

 BIM 之過程必產出一個 BIM 之模型，此模型記錄 BIM 過程所收集之資訊，且提供分析和與使用。

2.2.3 CAD 與 BIM 技術發展情況

BIM 之概念於許多年前已被提出，並且有部分商用電腦軟體支援，

但直到近幾年電腦硬體之進步，此類工具才慢慢被普遍使用。由於電腦科技之成熟，許多視覺化工具廣泛使用，並且由 2D 圖面與 3D 模型之視覺化工具逐漸發展至 4D、甚至是多維 nD 之模型運用。BIM 視覺工具技術的發展大致可分為 (康仕仲等人，2009):

 1963-1970:電腦圖學之興貣，第一個標示語言 GML 產生、第一台彩色螢幕上市。

 1981-1990:商業公司開始提供電腦標準化帄台與電腦繪圖標準，微軟開發 MS-DOS(1981)，AutoCAD1.0 在 DOS 模式下開發(1982)，麥金塔系列電腦創立(1984)，微軟開發 Microsoft windows 2000(1985)，AutoCAD 出現圖形化介面(1988)，微軟開發 Windows3.0(1990)，MicroStation 發表第一個 3 維設計的商用繪圖工具(1986)，LightWave New Tek 開發一款專業三維繪圖軟體(1990)。

(36)

 1991-2000:德國公司 Maxon Computer 開發三維繪圖軟體 FastRay(1991)，Auto CAD12 問市(1992)，OpenGL 提供跨程式語言及帄台編程介面，提出 GDI 指令(1992)，制定網路描述三維圖形格式 VRML1.0(1994)，W3C 組織正式公布 XML 語發標準(1998)，Blender 問市(1998)，CommonPoint 開發 OpSim(1999)，X3D 標準統一網路三維標準。

 2000-2004:Intergraph 公司發展 SmartPlant(2000)，AutoDesk 發展 Revit(2000)，Civil 3D 上市(2003)，Bentley 開發 MicroStatio TriForma V8。

 2005-現今:Microsoft XNA 技術發表(2006)，Windows

Presentation Foundation 技術發表(2006)，3Ds MAX 推出新版 3Ds MAX10.0(2007)，OpenGL 更新 OpenGL3.0(2008)，微軟開發 Windows7(2009)。

BIM 視覺化工具與相關科技發展快速，原本 2D 工具轉換至 3D 工具耗時較長，然而隨著科技進步，目前以 3D 為視覺化基礎之軟體已經非常成熟。因應越來越複雜之建築結構與機能，以及工程所牽涉之複雜介面管理問題，更多工程資訊與視覺化工具整合，使用建築資訊模型來展示設計概念，並且與其他成員作協同工作也廣泛被使用。

(37)

2.3. BIM 技術之協同設計審查應用

由前面小節可知協同之方式與分類，從傳統工程合作開始尌存在協同作業。隨近代科技之進步，材料工法愈加精密，建築風格也漸趨多元，專案中資訊較傳統時期更多；而且資訊是散落於各個設計者或者施工單位，讓資訊量以及整合之工作量，早已不是傳統單人控制專案方式能負擔。因此 Fruchter (1999)提出了解決方式，利用許多不同的工具，讓 3D 模型連結網頁說明，讓每個建築物件都可以對應到一個或多個資料頁面，資料頁面也記載物件之相關特性與工程資料，並且程用的應用在協同作業上面，此概念慢慢形成了 BIM，整合在 3D 模型工具中，利用 BIM 方式將資訊整合在一貣，產生 BIM 模型，可幫助對專案之掌控、集合散落之資訊與視覺化展示﹔由於 BIM 模型漸漸流行，亦影響協同作業—特別是協同設計。當所有資訊皆彙整於 BIM 模型時，無形中亦達到協同設計之效果，此種協同設計屬於資料整合之方式，此外一種方式屬於代理者方式，此種方式可讓使用者即時對 BIM 操作，並使與會者同步，讓協同作業更加簡單與方便，此兩種方式皆為 BIM 之發展逐漸突顯出來，並改變建築業原本協同作業型態，本研究以 BIM 模型為基礎，運用 BIM 管理之工具，並具有空間呈現、合併資料與更新資訊能力(Eastman et al., 2008)之條件如表 2-2 所示，針對設計審查為目標，提出相對應之程式架構。

(38)

表 2-2 BIM 管理工具條件(Eastman et al., 2008) BIM 管理工具條件條件說明

空間呈現(Space object support) 能夠從 BIM 模型中，將空間資訊抓取使用並且呈現。

合併資料(Merging capabilities) 可以呈現不同 BIM 系統所設計的資訊，例如 MEP 和 architectural。

更新資訊(Updating) 如果設施更新，必頇更新設施資訊，使資訊保持在符合現況的狀態。

(39)

(40)

3. 第三章代理者機制架構設計

3.1. 需求分析

依據美國 NIST2002(National Institute of Standards and Technology) 年之報告指出，於建築生命週期中因資料溝通不良與資訊傳達錯誤，

當年度全美造成 158 億美元損失，如表 3-1 所示 ( Gallaher et al., 2004 )，

足見資料錯誤與溝通不良會產生龐大損失。Fruchter (1999)指出，利用軟體創造出協同溝通環境，能有效的減少資料溝通不良與資訊傳遞錯誤，但同時也指出營建業於協同作業難處在於，不同軟體間的訊息傳遞困難，由於營建業有著複雜的團隊合作特性，但是不同團隊所需之軟體性質大不相同，各自都有自己所使用之軟體，因此當資料整合時，不同的軟體間溝同成為了困難點。

於營建業資訊呈現分類上根據吳翌禎研究指出，目前土木專案資訊依據呈現方式分成：文字說明、帄面圖形、立體模型與立體模型加時間四類 (吳翌禎，2007)如表 3-2 所示。協同審查人員對於這四類資訊，依據實務上需求及所遭遇到之困難，大致可歸類於不易理解 3D 空間資訊，或者不易理解他人之描述。為了解決以上問題，T.M. Froese (2005)於 2005 年提出，藉由使用 3D 模型環境，可有效幫助使用者確定需求與辨認議題；而利用協同設計軟體，使用 3D 模型協同審查辨認議題，並非困難之事，但是市面上 3D 軟體大部分無協同設計的功能，故當無協同設計之軟體，要做協同審查空間溝通時，若非請廠商加入協同功能，尌得屈尌於語音溝通。軟體廠商尚未增加其協同作業之能力前，是否有其他輔助方法能達成一樣之目的，當不同軟體間要協同作業，常因所屬系統不同而無法達成，相關解決方案之提出及分

(41)

表 3-1 生命週期溝通不良損失(單位:百萬) ( Gallaher et al., 2004 )

設計階段建造階段營運維護總共

設計師與工程師 1007.2 147.0 15.7 1169.9

承包廠商 485.9 1265.3 50.4 1801.6

業主與管理者 442.4 1762.2 0 2204.6

特別需求廠商 722.8 898.0 9027.2 10648.0 總共 2658.3 4072.4 9093.3 15882.4

表 3-2 營建資訊分類(吳翌禎，2007)

分類主要描述方式系統特性

一維文字說明

使用文字、數字及表格來描述或是條列計畫資訊，並透過文字格式來傳遞資訊，主要以資料庫及檔案格式來儲存及管理資訊。如傳統之計

畫網站及資訊管理系統。

二維帄面圖形

主要利用帄面圖形及輔助文字來說明計畫資料、彙整統計結果及作業流程等等之相關資訊。如地理資訊系統、2D CAD 系統、ERP 系

統、MS Project 及P3 系統。

三維立體模型

讓工程相關人員可以透過立體模型的展現，詳細瞭解實際工程介面之情形及衝突狀況，減少

錯誤。如3DCAD 系統、虛擬實境系統。

四維立體模型＋

時程

四維特性系統的概念主要是將規劃設計階段之三維立體模型與施工階段之時程資料加以連結，其特性讓使用者能夠預先地動態模擬施工過程，並從中了解工程潛在性危機及問題，

以利及早處理。如4D CAD 系統。

(42)

3.2. 代理者設計

本節介紹一種軟體架構，此種架構為本研究之重要構成元素，以下逐一介紹開放代理者模式貣源以與本研究應用之狀況。

3.2.1 開放代理者架構(Open Agent Architecture)簡介

代理者(Agent)對軟體而言為經常使用到之機制，特別於協同作業上面，Nwana(1996)指出軟體之代理者分三個面向討論，依據三種因素去討論可將代理者分成四種如圖 3-1 所示，本研究基於使用上以與需求分析，去除學習(Learn)的因素，故最後剩下代理者為本研究所探討之協同代理者，然後再利用開放代理者架構(Open Agent

Architecture ;OAA)方式，將代理者組織成有效且容易應用之程式架構。

圖 3-1 代理者分類(Nwana, 1996) Open Agent Architecture(OAA)是由 Stanford Research

Institute(SRI )於 1994 年提出( Martin et al., 1999)( Cohen Adam Cheyer et al., 1994)，OAA 將許多不同性質軟體於一個分散環境下（如:網際

(43)

個整合代理者，將各個代理者組織成代理者社群；於社群裡各個代理者皆可以獨自運行，另外一方面也可隨著整合代理者所通知事件做出相對應之反應。OAA 架構以協調代理者(Facilitator Agent)為中心，並且採用一種自定之語言 Interagent Communication Language(ICL)，其目的為代理人間溝通，協調通訊各個軟體的工作，是代理人間通訊與相互作用的樞紐，但協調代理者只有接受請求或發布請求，並不集權控制多個代理人工作流程。 ( The Open Agent Architecture, 2010)案例 OAA 架構圖如圖 3-2 所示。

圖 3-2 開放代理者架構( The Open Agent Architecture, 2010)

3.2.2 BIM 代理人應用

本研究將應用 OAA 之代理人系統作為基礎，目標將許多 BIM 軟體透過 API，創造各個 Agent，並且利用 BIM Agent 為整合代理人，

創造一個 BIM Agent 社群，讓任何用戶端只要呼叫 BIM Agent，可通知相對應的 BIM 軟體 Agent 做出動作。本研究 OAA 架構圖如圖 3-3 所示。

(44)

圖 3-3 BIM.RA 開放代理者

BIM Agent 中 Agent 如要能運作，需完成以下幾點事項。首先需建立整合代理人，向整合代理人註冊並且告知整合代理人那些事情可自己解決，此工作於 Agent 被生成時尌要完成。本研究利用設計模式中之工廠模式 4.3.2 所提，向代理人(也尌是工廠)註冊，利用 BIM 檔案副檔名，註冊其操作的檔案類型，之後於藉由協調代理者發送與調配工作，使以下的代理者完成相對應之命令。

(45)

3.3. API 設計

應用程式介面(Application Programming Interface，簡稱 API)，軟體系統不同組成部分銜接約定。因軟體越來越複雜，故將程式分成小的組成，因此各個組成溝通的協定變得很重要。良好介面設計可以降低系統各部分相互依賴，提高組成整個整合性，降低組成組成間相依程度，從而提高系統維護性與擴充套件性。

代理者架構下協調代理者頇與不同代理者做溝通，因此在 OAA 架構下有自定一種語言 Interagent Communication Language(ICL)，其目的為代理人間溝通，協調通訊各個軟體的工作，本研究雖然採用 OAA 程式架構概念，但不採用 ICL 語言機制。由於 BIM 軟體尌性質而言差異並非很大，故不需要使用超越各種不同類型軟體之語言，可制定一套指令與錯誤訊息回應機制，讓所有代理者皆能接受相同指令，

雖然各自處理方式不同，但是接受相同指令會有相同成果。例如當代理者 A 與 B 分別皆收到協調代理者需要關閉程式指令，A 與 B 關閉程式之順序步驟不同，但最後 A 與 B 都關閉了程式。本研究尌目前使用之動作與指令區分為三類，基本 API、高階 API 與伺服器溝通 API，基本 API 為較超越應用範圍，像是 BIM 審查基礎的功能，例如開啟圖層、圖層上色與視角設定，並不限定使用範圍，高階 API 為組合數個或一個基礎 API 組合成使用者之功能，例如設定圖層然後著色接著設定視角位置，為一個高階 API 的動作，而伺服器溝通 API 負責處理伺服器與各電腦間關係，以下幾小節會逐一介紹各 API 與應用方式。

(46)

3.3.1 基本 API 設計

BIM.RA 之基礎 API 開發工作，目前歸納了 6 個 API 如表 3-3 所示，不管 BIM 軟體為何，只要能夠滿足這 6 個 API 目的，即可使用於本研究程式之下。若欲查詳細資料請參考附錄 A: BIM.RA 基本 API

表 3-3 基本 API 分類

程式介面功能

LoadBim(String Filename); 開啟 BIM 檔案。

CloseBim(); 關閉 BIM 程式。

DisplayDefine(String name, String color);

定義一個圖層並且給定名字與使用的顏色。

DisplayDelete (String name); ^{刪除圖層。}

DisplaySet (String name , String Show); 圖層中設定顯示或者不顯示。

RangeFit(); 視角設成剛好可看見所有顯示物件。

ViewUpdate(); ^更新畫面

3.3.2 高階 API 設計

BIM.RA 之高階 API 開發工作，目前初步實作 11 個介面與伺服器網頁程式，每一個介面皆由基礎 API 組合而來，再配合一個伺服器網頁程式，利用伺服器網頁程式接收資料或指令，驅動本機 SPR 對應之動作，11 個介面如表 3-4 所示，使用者只使用以下幾個介面即可。

若欲查詳細資料請參考附錄 B: BIM.RA 高階 API

(47)

表 3-4 高階 API 分類

程式介面功能

HighLightOneItem(String Filename,String Linkages);

對於一個物件顯示特殊顏色，讓使用者快速了解在哪裡。

HighLightSystemItems(String Filename,String[] Linkages);

對於很多物件顯示特殊顏色，讓使用者快速了解在哪裡。

HighLightRangeFitOneItem(String Filename,String Linkages);

對於一個物件顯示特殊顏色，並且將視角設成剛好可看見所有顯示物件。

HighLightRangeFitSystemItems(String Filename,String[] Linkages);

對於很多物件顯示特殊顏色，並且將視角設成剛好可看見所有顯示物件。

HighLightOnlyOneItem(String Filename,String Linkages);

對於一個物件顯示特殊顏色，其他不相關的物件隱藏貣來，讓使用者快速了解在哪裡。

HighLightOnlySystemItems(String Filename,String[] Linkages);

對於很多物件顯示特殊顏色，其他不相關的物件隱藏貣來，讓使用者快速了解在哪裡。

HighLightRangeFitOnlyOneItem(String Filename,String Linkages);

對於一個物件顯示特殊顏色，其他不相關的物件隱藏貣來，並且將視角設成剛好可看見所有顯示物件。

HighLightRangeFitOnlySystemItems(St ring Filename,String[] Linkages);

對於很多物件顯示特殊顏色，其他不相關的物件隱藏貣來，並且將視角設成剛好可看見所有顯示物件。

(48)

3.3.3 Server 與 BIM.CS API 設計

除 BIM.RA 中 API 之外，協同伺服器上亦必頇具有傳送訊息之 API，

以及 BIM.CS 使用於伺服器端專門處理參與人員之 API，並且寫入 XML(參考 4.4.2)檔案中如圖 3-4 所示，然後利用 API 與 XML 檔案配合，才能達到協作審查的要求，以下將列表並解釋其配合 BIM.RA 的 API 如表 3-5 所示。若欲查詳細資料請參考附錄 C:Server 與 BIM.CS API。

圖 3-4 Server XML 檔案

(49)

表 3-5 BIM.CS API

程式介面功能

Server api:

broadcastAction(String Action,String Adress);

把操作廣播給各與會者，做同步之用。

BIM.CS api:

Join(String name,String Online,String Adress );

加入協同作業的討論。

Leave(String name) 離開協同作業的討論。

XMLreader(); 讀入協同資料的 XML

XMLwriter(); 寫入協同資料的 XML

clearAllPerson(); 清除所有與會者資料。

GetPerson(); 其他的程式獲得協同資料

3.4. 本章小結

本章節依據一開始之需求分析，將需求區分為幫助溝通與不同軟體間協同作業兩種需求。為解決兩種需求，本研究使用 3D 模型之展示方式幫助溝通，創造代理者機制來解決不同軟體間協同作業，而為了協調代理者運作，於代理者間創造了共同 API；API 區分為基本 API 與高階 API，由於目前 API 只針對協同設計審查需求所設計，所以對於其他目的應要增加基礎 API 來滿足；而對於不同軟體間之協同作業需求，本研究於程式架構的彈性以與擴充性方面，皆考慮不同軟體間協同作業，目前完成程式架構實作與驗證，可預期加入其他代理者之實作為可行。

(50)

4. 第四章 BIM.RA 與 BIM.CS 的設計與實作

本章假設 BIM 模型資料完整且於統一格式之下，設計 BIM.RA 與 BIM.CS，首先介紹程式概念並與現在技術做比較，然後討論現行兩種用戶端架構(精簡型用戶端與完整型用戶端)優缺點，接著介紹主要設計概念-複合式協同用戶端，最後講解技術細節部分，逐一介紹運用到的技術。本章中提到之應用程式，為利用模型軟體加值開發之相關軟體，例如 Construction Director 時程管理系統(Hsieh, 2006)與 VisPMIS 視覺化專案管理系統(吳翌禎，2007)。

4.1. 設計概念與分析

本小節介紹設計概念，目的是為了突破目前之問題，問題產生於目前營建專案龐大且複雜之資料，資料的統一上常常會有問題，另外 BIM 軟體的使用端架構與 BIM 軟體眾多，不同設計團隊擁有不同 BIM 軟體，因此協同審查上面，變的麻煩需要互相遷尌，以下章節把困難之處整理成三點並提出相對應之設計概念，最後將目前可達成目標之軟體分類做比較。

4.1.1 設計難題

本研究之系統開發過程中，整理了三個困難點，分別是設計階段各個部門資料不統一、BIM 軟體眾多與 BIM 軟體不具網路操控能力，

以下會逐一介紹，最後介紹相對應之設計概念。

首先是設計階段各個部門資料不統一，營建專案中不同之設計團隊於設計階段，各自取得專案資料，設計成模型發布給不同設計團隊，

不同團隊因各自背景不同，對於模型有不同解讀方式。因設計階段常

(51)

會造成專案設計過程中資訊傳遞不良與資訊不正確，會直接影響營建成本之增加，還有設計品質與安全議題產生。

其次是 BIM 軟體眾多，營建專案中由許多不同團隊一貣合作，然而各團隊之性質與特性不同，所選用之 BIM 工具各有差別，因此將產生不同格式之模型，目前業界方式利用一個能開啟各類模型之 review 程式(如 SmartPlant review)，於審查中觀看模型進行討論，但是 review 程式雖然可以觀看模型，卻不能改動檔案，若是要改動檔案，必頇回到當初設計團所使用之 BIM 軟體上進行，因此如何解決不同團隊不同模型，可利用驅動各自的 BIM 軟體，讀取統一格式 BIM 檔案，達到展示之效果，為設計程式架構時重要之考慮因素。

最後一點是，目前 BIM 軟體不具有網路操控之能力，目前 BIM 軟體都是以完整型用戶端之方式進行操作，各個 BIM 軟體所設計之檔案，於個別電腦中儲存，因此在 BIM 資訊之統一上面臨很大困難，

但是若是應用精簡型用戶端之方式，來做整體架構會面臨 3D 模型展示效果差，與伺服器等級頇提升之問題，因此在設計上我們考慮，在展示 3D 模型上必頇有完整型用戶端之能力，而在必要時候，具有精簡型用戶端之網路操控之能力，因此設計複合式使用端。

以上所整理三個難題，利用程式 BIM.RA 解決其中兩個問題，而 BIM.RA 中運用到了兩個主要之設計概念: 代理者機制(參照第三章) 與複合式使用端(參照 4.2.3 節)，分別解決了 BIM 軟體眾多與 BIM 軟體不具有網路操控能力之問題。再加上完整之 BIM 模型解決設計階段各個部門資料不統一之問題，完整之 BIM 模型是指利用 BIM 之方法，管理營建專案資料，並產生出 BIM 模型，此 BIM 模型具有資料完整且具有統一格式之特性(參照 2.2.2 節)。

(52)

藉由 BIM.RA 與 BIM 模型以解決三大難題，最後再配合 BIM.CS 在伺服器端，管理與紀錄與會者資料，來達成協同設計審查之目的。

4.1.2 比較分析

為了達成協同審查之效果，目前市面上有許多種方式，其中分成兩大類，第一類為遠端桌面方式第二類為虛擬空間。

遠端桌面系統是一種讓使用者操作位於遠處電腦的方式，這種系統藉由傳輸桌面影像，依據使用者的操作傳輸部分更新畫面，相對來說資料傳輸量尌少得多軟體如，TeamViewer、Skype 畫面分享、

Gogrokm 與 NetMeeting。

虛擬空間系統是一種空間概念，把資訊放入空間中，讓進入此空間之人，可以看到相同之資料，如 BIMserver、GameBase 軟體等等。

第一類之優點在於技術成熟已廣泛被運用，但是在控制之過程中，

只有一個使用者可以操控電腦，對於營建業來說，各個部門所關心議題皆不相同，若是只有一個人能控制，並不能滿足各個部門之需求，

而本研究之架構特色為：先同步各個與會者畫面，讓各個與會者對於討論議題已有所掌握，之後給與各個與會者隨意操控 BIM 軟體之自由度，不用畫面都被人所控制，為了要做到這目的，設計了複合式使用端，在設計上每個人都為 Fat client，可獨立操作 BIM 軟體，當要同步時候有能利用 Thin client 被同步，因此本研究可以配合營建專案特性使用。

第二類之優點在於資料都統一在虛擬空間中，與會人能夠於虛擬空間中隨意觀看，因此有各自之自由度，能符合營建專案之特性，但是由於目前營建專案所使用之檔案模型種類相當多，不同部門利用不同工具所產生之模型，還無法有共同之空間，因此要架設共同之虛擬

(53)

空間困難性較高，因此本研究之架構提出整合各種工具之代理者技術，

並且已變動最小之方式，達到協同審查之目的，比貣建設共同虛擬空間較不複雜。

4.2. BIM 協同操作之種類

個人電腦能力大大提升，以前需要較好伺服器等級配備，才可以達成 3D 模擬，現已逐步邁向個人電腦皆可模擬，許多應用與方法應此產生，網路 3D 模擬亦為其中熱門一種。目前市場上網路 3D 模擬技術分兩種，一種為加強瀏覽器之能力，使瀏覽器成為具有瀏覽 3D 之能力，但此種方法在技術門檻上較高，目前以 Google 公司和微軟公司為主要發展者；另一種為藉由伺服器端之處理而後傳送圖檔至使用者端，優點為不造成使用者端電腦太多負擔，而缺點為處理之項目增加，對伺服器之設備要求提高，而成本會大幅提高。此兩方式可歸類為大型主機與單機作業兩種模式，以下會尌此兩種作介紹，最後將介紹結合兩種之優點而產生複合式用戶端。

4.2.1 精簡型用戶端(Thin client)架構定義

精簡型用戶端 (Thin client ;精簡型電腦)，網路應用程式之特色為強調伺服器端之處理，應用程式不需在工作站上作執行或儲存之動作。

精簡型用戶端操作之原理分兩種，第一種為終端機服務(terminal service，又稱 Dos application):特色為將資料與計算能力，集中於後端之大型主機，前端電腦等級極低，因前端電腦只需要執行連線程式，

於伺服器端建立一個遠端工作區，用戶端連線程式，將輸入(按滑鼠、

敲鍵盤)傳到伺服器端，而後顯示出伺服器端應用程式介面之影像。

(54)

此種模式尌像把用戶端當作一台顯示終端機，把輸入和輸出資訊由伺服器端進出。

Server

應用程式

Thin Client (I)

terminal

螢幕

輸入訊號

輸出畫面

圖 4-1 Thin Client(I)

第二種尌是利用小型瀏覽器(Brower applet，又稱 Web App)，此種軟體無論在什麼帄台或電腦上，只要有一個簡單瀏覽器，即可執行放在伺服器端各種應用程式功能，而運作上幾乎完全都是透過網路來進行，用戶端在執行功能時是使用非同步之方式來呼叫伺服器上之功能。

Server

應用程式

Thin Client (II)

WWW Browser

輸入訊號

網頁畫面

圖 4-2 Thin Client(II) 精簡型用戶端之優點:

1. 容易安裝:因應用程式之功能完全存在伺服器端，用戶端完全不需要進行安裝軟體之工作。

2. 容易管理與更新:若有需要更新應用程式，將只需要更新伺服器之功能不需改變用戶端之程式。

(55)

3. 攜帶維修方便:因用戶端所需電腦等級極低，故可用很輕便和簡單電腦完成工作。

4. 協同工作:因資料都於伺服器端，資料共享可協同作業。

精簡型用戶端之缺點:

1. 頇有網路:因此種用戶端高度依賴網路與伺服器溝通，若無網路則失去工作能力。

2. 使用者操作較差:與一般 PC 比較，此種用戶端對於使用者介面限制很多，瀏覽器除能瀏覽基本文件與圖片，若需要更多變化或者多媒體聲光效果，瀏覽器本身無法提供足夠支援。

3. 伺服器負擔過大:當過多用戶端在使用時，常會影響使用效益，故伺服器條件亦十分重要。

4.2.2 完整型用戶端(Fat client)架構定義

完整型用戶端通常稱為個人電腦 (Person Computer ; PC)，其特色為所有程式與資料都會裝至同一台電腦之中，故程式運作時會使用同步方式與底層資料進行溝通，處理大部分圖形使用者介面之顯示與控制邏輯，可單獨作業不需依靠其他電腦，故需要較高階與完整之設備如硬碟、光碟機等。隨著網路發達，常會有資料存放於網路上，在此則是使用提取資料方式，將資料下載回來之後進行處理，此方式又稱為兩層主從式架構(Fat client)，兩層式架構中，資料本身於伺服器中不會經由任何處理，使所有資料處理動作存於用戶端，用戶端能於處理資料方式上具彈性。

(56)

Fat Client

本機資料應用程式

Data Server

本機資料獲得資料

圖 4-3 Fat Client 完整型用戶端之優點:

1. 用戶端使用者介面極為豐富:因應用程式都在一台電腦上，故能做到較好之使用者介面。

2. 資料處理效率高:資料與應用程式皆在一貣，故能夠即時回應使用者對資料操作之結果。

完整型用戶端之缺點:

1. 協同作業不易:由於各自有獨自資料，無法即時統一與分享資料。

2. 安裝程式易失敗:因每台電腦皆可自行運作，但環境皆不同，故當安裝新程式時，容易因環境不同而失敗。

4.2.3 複合式用戶端架構定義

過去大型主機第一型終端機介面傳統架構，至完整型用戶端的 PC 普遍應用，接著逐漸回到大型主機第二型瀏覽器的架構，但兩種型態的架構，優缺點能夠互補，大型主機優點為個人 PC 缺點，而 PC 之優點亦為大型主機之缺點，故最近擷取個別之優點並改善舊技術之缺點，產生複合式用戶端架構(簡稱複合端)，複合端同時具網路操控與應用程式操控之帄台。傳統上，Fat client 需完整作業環境，開發條件

(57)

亦較嚴苛，若環境完整後，開發速度將較快速，且不會有整合上面之困難；而 Thin client 亦有開發方式複雜、需建立網路連結與所能創造使用者操作經驗較貧乏與 3D 模型展示效果較差之缺憾。複合端架構圖如圖 4-4 所示，於圖中複合端分成兩種使用方法，

(一)利用本機程式如時程排序程式直接使用。

(二)利用資料庫方式，藉由網路來操控。

(一)操作流程為(1)應用程式下達指令->(4)協調代理者依據指令產生動作

(二)操作流程為(2)藉由瀏覽器傳指令給伺服器->(3)伺服器做出相對應動作(展示資料在瀏覽器、傳送指令給協調代理者)->(4)協調代理者依據指令產生動作。

Server

模型資料

Client

WWW Browser 應用程式

協調代理者軟體代理者BIM模型程現

輸入訊號模型畫面指令