• 沒有找到結果。

第三章 臺灣COBie-TW標準的本土化探討

第一節 英國規範內容探討

英國標準協會,BS1192-4:2014 年資訊的協作式產出第四部份:使用 COBie 業務守則履行 業主的資訊交換需求(British Standards Institution, BS 1192-4:2014 Collaborative production of information Part 4: Fulfilling employer’s information exchange requirements using COBie)作為英國 COBie 的規章,將 COBie 定義為一種方法,可以將建築物和基礎設施內有關設備之各結構化資

1. BS 1192:2007, Collaborative production of architectural, engineering and construction information –Code of practice

BS 1192:2007 年,建築、工程和施工資訊的協同作業-工作守則,使用設施和資產資訊 建模基礎的設計,施工和使用合作專案的管理考績 1192-2 和 1192-3 的 PAS 文件的最佳實務。

2. PAS 1192-2, Specification for information management for the capital/delivery phase of construction projects using building information modelling

PAS1192-2,採用建築資訊模型的營建專案,在資本/交付階段的資訊管理規範。

3. PAS 1192-3, Specification for information management for the operational phase of construction projects using building information modelling

PAS1192-3,採用建築資訊模型的營建專案,在營運階段的資訊管理規範。

4. BS ISO 16739, Industry Foundation Classes(IFC)for data sharing in the construction and facility management industries

BS ISO16739,在營造和設施管理產業中,對產業基礎類別庫(IFC)的資料分享。

英國進行 BIM 的產業轉型政策上分成四個階段,根據資訊自動化整合的程度分成 Level 0

到 Level 3 逐步落實,COBie 標準的應用是在 Level 2,部分的資訊與檔案文件是可以自動的連 接整合。

圖 3-1 英國對於 BIM 的規範計畫(圖片來源: BS1192-4:2014)

以 COBie 的通用視域來說,交換的範圍由「設施」決定,它是一個界定的營運單位,通常 指一棟建築物或土木水利基礎設施某段落或某區域 – 依循臨時性專案和永久性地址的細節。

COBie 的內容包含有關構成設施的空間位置,以及設備與元組件的資訊。為了使該設施生命週 期期間可以被管理,空間位置被配置給中介位址或位置,並且置入其它空間群組及設備。元組 件資訊被設定成“一般規範”, “功能群組”的分類則是依它們的功能目的。

圖 3-2 是 COBie 對於基礎設施,整個資產包括所有的設施,以及組構它們的位置和元組件 的說明。這些都是透過群組到分區、區域、類型和系統來進行管理。

圖 3-2 COBie 的基礎設施視域

(圖片來源: BS1192-4:2014,本研究團隊郭榮欽老師繪製)

圖 3-3 是 COBie 在建築方面,整個資產包括所有的設施,以及組構它們的空間和元組件。

這些都是透過群組到分區、樓層、類型和系統來進行管理。

圖 3-3 COBie 的建築視域

(圖片來源: BS1192-4:2014,本研究團隊郭榮欽老師繪製)

從第 3 章(Terms and definitions)開始是術語和定義,本研究節錄部分內容,藉此說明英國規 範的內容與架構:

3.1 Asset 資產 3.1.1 assets 資產

3.1.2 Component 元組件

3.2 Construction Operations Building information exchange (COBie)施工營運建築資訊交換 3.3 digital Plan of Work (dPoW) 數位化工作計劃

包括階段、角色、職責、資產和屬性等資料的一般性明細表,在一個可計算的格式中建置 的。

3.4 Employer’s Information Requirements (EIR)雇主的資訊需求

招標前列出工程完成需被交付的資訊之文件,以及供應商在專案交付過程中須遵循的標準 和流程。

3.5 Operational information 營運資訊 3.5.1 Job 工作

3.5.2 operational information 營運資訊 3.5.3 Resource 資源

3.5.4 Spare 備品

第 4 章討論業務流程(Business process),根據各角色檢討其的職責與工作,分析所應提供與 接受的資訊。其討論內容如下:

4.2.1 Employer’s role 業主的角色

4.2.2 Designers, contractors and service providers role 設計師、承包商和服務提供商的角色 4.2.3 Supply chain role 供應鏈的角色

4.3 Provider/Receiver relationships 提供者/接收者的關係 4.3.1 General 一般

4.3.2 Strategic actions of the information provider 資訊提供者的策略行動

4.3.3 Management and quality assurance actions 管理和品質保證措施 4.3.4 Implementation actions 實施行動

4.4 Processes over the Facility lifecycle 跨設施生命週期的流程

圖 3-4 COBie 資訊交換流程

(圖片來源: BS1192-4:2014 本研究團隊郭榮欽老師繪製) 第 5 章 Purposes 用途,其討論內容如下:

5.1 General 一般

資訊的提供應該支援雇主在管理此設施的用途,其中包括:

 當被要求交付資訊時,應參照到符合設施(Facility)生命週期階段

 被參照到 5.2,5.3 和 5.4 中有包括或排除在外的用途,連同任何額外附加的目的。每 個用途都應該被明確地詳細列入、或從 EIR 內剔除

 任何額外的驗證、檢測和指標部分,被延伸到第 6 章的內容

 任何額外的內容補充在第 7 章。這也同樣定義了“requirable”(可能需要)欄位,表示 被需要或被剔除的欄位(參考附錄 A),以及任何被需要的特定屬性(Attributes);以及

 如果有其他的文件檔案和模型格式也同樣會被接受,這些文件檔案(Documents)應該被 關聯到相對應資產的“Document”表單內

5. 2 Overall purposes requiring information 要求資訊的整體用途 5.2.1 General 一般

5.2.2 Register 註冊

5.2.3 Support for business questions 業務問題的支援

5.2.4 Support for compliance and regulatory responsibilities 支援合規性和監管職責 5.3 Management of facility benefits 設施效益之管理

5.3.1 General 一般

5.3.2 Management of capacity and utilization 效能管理及使用率 5.3.3 Management of security and surveillance 安全管理與監控 5.3.4 Support for repurposing 支援再利用

5. 4 Management of Facility Impacts 設施管理的影響 5.4.1 General 一般

5.4.2 Predicted and actual Impacts 預測與實際影響 5.4.3 Operations 營運

5.4.4 Maintenance and repair 維護和修理 5.4.5 Replacement 更換

5.4.6 Decommissioning and disposal 報廢和處置

第六章 Management and quality criteria 管理和品質標準 6.1 General 一般

資訊提供者應提供管理和品質監督以及需求的審查,在本章後面會列出相關的需求審查。

測試應該是針對 COBie 定義綱要之合規性,與隱含在這章和第 7 章的額外特殊需求規則。

6.3 Structure 結構

COBie 應該交付的是“電子試算表 XML 2003”格式的單一模型。這種格式對大多數電子 試算表和資料庫應用程式是可以接受的。含有巨集或其它嵌入式程式的格式,有可能會被防火 牆和安全掃瞄拒絕。其特性有:資料類型(Data types)要與 COBie 樣板一致;命名要清晰(Clarity of naming);單位要一致(Consistency of units)

6.4 Consistency (一致性)

COBie 交付從一開始應該有連續性及累積發展,以利比較和核對作業。唯一的資產名稱應 從早期交付起開始維持。外部系統(External System)標識,如全區唯一標識(Globally Unique Identifiers、GUID),應予以保留。

常數性屬性(Constant Attributes)、常數性文件(Constant Documents)、常數性影響(Constant Impacts)都應被指定到:

類型(Type)或系統(System),而不是元組件(Component);以及 樓層 Floor(地區)或分區(Zone),而不是空間 Space(位置)。

6.5 完整性(Completeness)

資訊交換之前的任何交付作業,應透過適當的審查和測試進行完整性的評估。應符合以下 條件:

 準確性(Veracity):提供的資訊應符合預期或實際上的設施。

 分組(Groupings)

 補充資料(Supplementary information)

 營運資訊(Operational information)

 及時性(Timeliness) 第七章 實施(Implementation) 7.1 一般(General)

7.2 方式(Means)

實施應該透過使用健全的應用程式、共享的結構化資料和可重複的流程來實現。

7.3 現有的和新的設施(Existing and new Facilities)

現有的設施和新設施的情況,應該於調查、文件審查和/或現有的資料中實施記錄。“未知”

的項目應該被添加到分類和其他表列欄位,以利幫助任何未知的屬性和量測,可以逐步建立文 檔資料。文檔資料建立情形的調查工作,應使用一致的多個選項評量尺度。

7.4 基礎設施和建築(Infrastructure and buildings) 7.4.1 一般(General)

如果有必要映射“區域”的設施到樓層(區域)表內,使用適當的空間結構記錄基礎設施和 建築設施,以確保檢查和維護的工作空間(位置)為可識別的“位置”目的地。

7.4.2 座標(Coordinates)

7.4.3 變化屬性(Varying Attributes)

7.5 設施生命週期管理(Facility lifecycle management)

詳細的資產管理應將代表需求性能的元組件(Components)要從全部組成中分離出來。這些

應該被連結成一項組裝(Assembly)。

7.6 資產一般要求(General requirements on assets)

資產的身份應提供,包括名稱(Name)、描述(Description)、分類(Classification)、外部系統 (ExtSystem)和外部標識(ExtIdentifier)(如果有的話)。資產應進行分類,並提供支援精確的審計和 報告。這應該包括規範和說明。分類應該從定義的表列來提供

7.7 Expected Attributes 預期的屬性 7.7.1 一般 General

7.7.2 Facility Attributes 設施屬性

7.7.3 Space(location)Attributes 空間(位置)屬性

空間(位置)屬性應包括標識、明顯數量和位置資訊。任何其他一致的屬性,應採用或推廣 到空間的(位置的)分區或樓層(區域)。

7.7.4 Component Attributes 元組件屬性

元組件的屬性應包括標識、明顯數量和位置資訊。任何其他一致的屬性,應採用或推廣到 流程圖(Process map)、交換需求(Exchange requirements)、功能構件(Functional part)、資訊交付手 冊(IDM)來說明應用的方式。目前 NBIMS-US V2 標準提供 10 個主要流程圖,說明流程配置、

參與角色、需要的資訊、使用與產生的資訊項目,供不同狀況參考使用。整理如下:

 (PM-1) Identify Submittal Requirements 確認審查要求

 (PM-2) Define Submittal Schedule 定義審查施工明細

 (PM-3) Transmit Submittal 傳送審查之流程

相關文件