重點摘要
- IDS（Information Delivery Specification，資訊交付規範）是 buildingSMART 的開放標準，IDS 1.0 已於 2024 年 6 月正式發布。
- 它解決的痛點：EIR 的資訊需求用文字寫，人看得懂、軟體驗不了——交付驗收只能靠人工抽查。
- IDS 把需求寫成機器可讀的 XML 規格檔：每條規格＝適用對象（applicability）＋要求（requirements），例如「所有防火牆（適用對象）都必須有防火時效屬性且值不為空（要求）」。
- IDS 檢核的對象是 IFC 模型——IDS 定義「要求什麼」，IFC 承載「實際交了什麼」，檢核軟體比對兩者、自動產出通過/不通過報告。
- 對台灣業主的意義：把 EIR 附錄的屬性需求表（LOI）轉成 IDS 檔隨招標文件發出，廠商交付前自檢、業主收件時複驗，用的是同一份規格、同一套判準，驗收不再各說各話。
問題：需求書寫了，模型卻驗不了
你在 EIR 裡寫了「機電設備須包含廠牌、型號、額定功率屬性」「所有門須標註防火時效」。廠商簽約時也承諾了。然後呢？
竣工交付時，模型裡有上萬個元件。要確認「每一扇門都真的填了防火時效」，靠人工只能抽查——抽查漏掉的，就變成維運階段才發現的地雷。這是 BIM 交付驗收長年的困境：
- 需求是文字，模型是資料：文字需求無法直接對模型執行，中間永遠隔著一層人工翻譯。
- 各家軟體各驗各的：廠商用 A 軟體的檢核規則自檢、業主用 B 軟體複驗，兩邊規則寫法不同，結果對不上，爭議就來了。
- 驗收成本高到只能形式化：認真逐項驗的成本太高，最後常淪為「有交檔案就好」——資訊交付驗證講的三層驗證，在屬性層次很難落實。
IDS 要解決的就是這件事：把資訊需求本身變成機器可讀、可自動執行的規格。
IDS 是什麼
IDS（Information Delivery Specification）是 buildingSMART International 制定的開放標準，1.0 版於 2024 年 6 月正式核定發布，是 openBIM 標準族（IFC、BCF、bSDD、IDS）的一員。
一個 IDS 檔是一份 XML 文件（副檔名 .ids），裡面裝著一組「規格（specification）」。每條規格回答一個問題：
模型裡的哪些東西（適用對象），必須滿足什麼條件（要求）？
軟體讀入 IDS 檔與 IFC 模型後，逐條規格自動比對，產出結構化的檢核報告：哪條規格通過、哪條不通過、不通過的是哪些元件。人不用再逐個點開元件看屬性。
IDS 檔案的構成：適用對象＋要求
每條規格由兩半組成：
| 區塊 | 回答的問題 | 範例 |
|---|---|---|
| 適用對象（applicability） | 這條規格管到誰？ | 所有 IfcDoor、且防火分類為「防火門」的元件 |
| 要求（requirements） | 被管到的元件必須滿足什麼？ | 必須有 FireRating 屬性，且值屬於「60 分鐘、90 分鐘、120 分鐘」之一 |
兩個區塊都用同一組「面向（facet）」來描述條件，可以自由組合：
| 面向 | 描述什麼 | 範例 |
|---|---|---|
| Entity（實體） | IFC 類別與型別 | 元件是 IfcDoor |
| Attribute（屬性欄） | IFC 內建欄位 | Name 欄位不得為空 |
| Property（性質） | 性質集內的性質 | Pset_DoorCommon 裡的 FireRating |
| Classification（分類） | 分類系統與編碼 | 依 Uniclass 或營建署編碼分類 |
| Material（材料） | 材料指派 | 材料為混凝土 |
| PartOf（隸屬） | 空間或組成關係 | 必須隸屬於某樓層或系統 |
要求的值可以指定「必須存在」「必須等於某值」「必須在清單/數值範圍內」「必須符合命名格式（pattern）」，也可以標示為必要、禁止或選擇性。這幾種組合已足以表達 EIR 屬性需求表裡絕大多數的條目。
一條規格用白話唸出來就像：「凡是外牆類的 IfcWall（適用對象），都必須有熱傳透率性質、值為數字、且小於等於 3.5（要求）。」——這句話同時是給人看的需求，也是給軟體跑的規則。
與 IFC 的關係：一個管需求、一個管資料
IDS 與 IFC 是一對搭檔，角色不同：
- IFC 是資料格式：承載模型「實際上交了什麼」——幾何、屬性、分類、關係。
- IDS 是需求格式：描述模型「應該要有什麼」。
- 檢核軟體 是裁判：讀入兩者，逐條比對，產出報告。
因此 IDS 檢核的前提是交付格式為 IFC（或可靠匯出 IFC）。這也回頭影響你的 EIR：如果要走 IDS 自動驗收，EIR 就要求交付 IFC，並指定 IFC 版本（如 IFC4）與匯出對應（哪個原生參數對應哪個 IFC 性質）——否則廠商模型裡屬性明明有填，匯出 IFC 時掉了，檢核照樣不過。
支援工具概況
IDS 1.0 發布後，主流工具陸續支援，大致分三類：
- 撰寫／編輯 IDS：試算表轉換工具、專用編輯器（如 ACCA usBIM.IDSeditor、線上 IDS 編輯服務），讓不寫 XML 的人也能用表格方式編規格。
- 執行檢核：Solibri、BIMcollab Zoom 等模型檢核軟體可載入 IDS 執行驗證；開源陣營有 IfcOpenShell 的 ifctester 與 Bonsai（原 BlenderBIM），適合整進自動化流程。
- 建模端自檢：部分建模與協作平台已支援在交付前直接以 IDS 自檢，讓「不通過的東西根本出不了廠商的手」。
工具支援度仍在快速變化，導入前建議以「你的檢核軟體是否通過 buildingSMART 的 IDS 相容性測試」為準，避免各家實作解讀不一。
與 EIR/LOI 的銜接：IDS 是 EIR 的「可執行附件」
IDS 不是取代 EIR，而是 EIR 中「可結構化需求」的機器可讀版本：
- EIR 管全局：交付時程、CDE 規則、權責分工、驗收程序——這些流程性要求仍然用文字寫。
- LOI／屬性需求表轉成 IDS：EIR 附錄那張「元件類別 × 必填屬性」的表（資訊詳細度 LOI），正是最適合轉成 IDS 的部分——它本來就是結構化的。
- 需求鏈不變：IDS 裡每條規格仍應能追溯回 AIR/PIR 的用途（見 OIR/AIR/PIR/EIR 四層推導），不是拿到工具就把規格寫爆。
值得留意：ISO 19650 的 2026 修訂草案強化了與 ISO 29481（IDM）等標準的對齊，「需求要機器可讀、可自動驗證」正是整個標準族系的共同方向（見 ISO 19650 2026 修訂動態）。現在投資 IDS，方向是順風的。
台灣落地情境
台灣公共工程可以從小處開始，不必一步到位：
- 從竣工屬性驗收切入：把 EIR 的竣工模型屬性需求表（設備廠牌、型號、保固、維護週期等維運欄位）轉成一份 IDS，隨招標文件發出。這是價值最明確、範圍最收斂的起點。
- 雙端同規：契約載明「以本 IDS 檔為屬性驗收判準」，廠商交付前用它自檢並附檢核報告，業主收件時用同一份 IDS 複驗——通過標準只有一套，退件不再有「你的軟體跟我的軟體驗出來不一樣」的爭執。
- 分期加嚴：第一期只驗「屬性存在」，第二期加「值域與格式」，第三期納入分類編碼與命名規則——配合里程碑逐步提高門檻，廠商有時間適應。
- 搭配人工驗證：IDS 管得住「資料對不對」，管不住「設計好不好」「衝突解了沒」——幾何協調、工程判斷仍是人的工作。自動化是把人力從逐格檢查解放出來，去做真正需要判斷的事。
下一步
IDS 補上的是驗收拼圖的最後一塊：讓 EIR 訂的需求，在交付末端能被逐條、全數、自動驗回來。至於驗證整體怎麼分層、誰驗、退件機制怎麼走，請接著看 資訊交付驗證——IDS 就是該文「合規性驗證」層次的自動化引擎。