Cross-System Building Intelligence / 概念設計與原型說明

Cross-System Building Intelligence

概念設計與原型說明（Concept Design & Prototype）

本文件為面試後，基於公開智慧建築／智慧社區案例所做的概念驗證。
內容用於展示跨系統後端設計、AI 應用邊界與可追蹤決策流程，不代表任何公司的實際 production architecture。
本 Prototype 使用的 telemetry、threshold、device ID 與 scenario data 皆為 synthetic data。

1. Executive Summary

智慧建築內通常同時存在多個彼此獨立的子系統，例如氣象、湖面監測、灌溉、排水、HVAC、能源與人流系統。這些系統各自能產生資料與警報，但對建築管理者而言，真正需要理解的往往不是「哪一個 sensor 超標」，而是：

多個分散事件是否其實共同描述同一個正在發生的問題？

本 Prototype 提出一個 Cross-System Building Intelligence 概念：先由後端將不同來源的 telemetry 標準化為 Observation，再以 deterministic rule 產生 Event，透過跨系統 correlation 建立 Incident；AI 則在 Incident 已成立之後，查詢建築的 Structured Digital Twin / Building Context，取得相關設備、能力、關係、目前狀態與歷史資料，進一步形成 evidence-backed analysis 與 recommended action。

系統刻意將「事實」、「規則判定」、「AI 推論」與「人工確認」分層保存：

Observation → Event → Incident → AI Analysis → Human Review → Action → New Observation

其中 Observation 是 source of truth。AI 可以補充解讀，但不能覆寫原始事實；AI 也不直接控制設備，任何動作需經人工核准後執行，操作後的新設備狀態再回到 Observation pipeline，形成可追蹤的閉環。

2. Background & Problem

智慧建築的問題並不是缺少資料，而是資料通常分散在不同系統中。

例如同一個社區可能同時存在：

單一子系統可以知道自己的狀態，但不一定知道其他系統同時發生什麼。

因此管理者可能同時看到：

若這些訊息分散在不同系統內，仍需要人自行判斷它們是否相關、是否需要處置，以及現場有哪些設備可以使用。

本 Prototype 想驗證的核心問題是：

能否把原本分散在不同 subsystem 的訊號整合成同一個 Incident，再結合 Building Context，讓 AI 產生可追溯、可人工審核的決策建議？

3. Product Goal

本 Prototype 主要驗證四件事。

3.1 Cross-System Understanding

將不同來源的資料標準化後，以明確規則產生 Event，再透過時間、位置與語意關係，把多個 Event 關聯成同一個 Incident。

3.2 Building-Aware AI

AI 不只看到：

HIGH_WATER_LEVEL

而能進一步查詢：

3.3 Evidence-Backed Analysis

AI 產生的結論需能回溯到實際 Observation / Event 與 Building Context，而不是只有自然語言敘述。

3.4 Human-in-the-loop Action

AI recommendation 不直接等於 execution。

所有具體操作需經：

AI Recommendation → Backend Validation → Human Approval → Action → New Observation

4. Target User

主要使用者：Building Operator / Facility Manager

他需要快速理解：

次要使用者：Building Engineer

需要進一步確認：

5. Product Concept

整體系統可以分成三個相互關聯，但角色不同的部分。

A. Incident Processing

負責回答：

發生了什麼？

流程：

Telemetry → Normalized Observation → Deterministic Event → Cross-System Incident

B. Structured Digital Twin / Building Context

負責回答：

現場有什麼？在哪裡？可以做什麼？目前狀態如何？

它不是事件資料流程中的一步，而是一個持續存在的 context layer。

結構：

Building → Zone → Device → Capability → Relationship → Current State / History

C. AI Decision & Audit

AI 同時取得：

Incident Evidence + Building Context

再產生：

Structured Analysis → Recommended Action → Human Review → Action Result

因此本 Prototype 的核心關係是：

Incident 告訴 AI 發生了什麼；Building Context 告訴 AI 現場有什麼可以理解與操作；兩者一起才形成 recommendation。

6. Core Flow

Step 1 — Telemetry Ingestion

接收不同 subsystem 的原始 telemetry。

Step 2 — Normalized Observation

將不同格式資料轉成統一 Observation schema。

Observation 是 source of truth，保存：

Step 3 — Deterministic Event Detection

Rule Engine 根據明確門檻產生 Event。

例如：

AI 不參與這一步。

Step 4 — Incident Correlation

Correlation Engine 根據：

將多個 Event 整合成 Incident。

Step 5 — AI Context Retrieval

Incident 成立後，AI 使用 tools 查詢 Building Context，例如：

Step 6 — Structured AI Analysis

AI 將 evidence 分成兩類：

事件證據

建築脈絡

輸出：

Step 7 — Human Review

管理者審核 AI recommendation：

Step 8 — Action

只有核准後才能進入 Action Service。

Step 9 — Feedback to Observation Pipeline

設備狀態改變後，產生新的 Observation。

因此形成：

Observe → Detect → Understand → Recommend → Approve → Act → Observe Again

7. Building Context / Structured Digital Twin

本 Prototype 的 Digital Twin 不以 3D 模型本身為核心。

核心是建立一份 可被後端與 AI 查詢的建築數位狀態模型。

資產結構

Building
├── Lake Zone
│   ├── Weather Station W01
│   ├── Lake Sensor LS01
│   ├── Irrigation IRR01
│   └── Drainage Pump DP01
│
└── Tower A
    └── Floor 3
        ├── AHU03
        ├── OCC03
        └── EM01

Device Capability

例如：

IRR01
- START
- STOP
- GET_STATUS

Device Relationship

例如：

W01   → affects    → Lake Zone
LS01  → monitors   → Lake Zone
IRR01 → operates   → Lake Zone
DP01  → controls   → Lake Water Level

Current State / History

例如：

IRR01 state = RUNNING
DP01 state  = STANDBY

AI 因此不需要「猜」現場有沒有排水設備，也不需要「猜」IRR01 能不能停止。

這份關係圖在真實專案中來自既有的 BIM / IFC 模型與 BMS point list，不是為了本系統額外產生的；其資料品質風險見第 15 節 Building Metadata Quality。

Recommendation 必須建立在實際 Building Context 上。

8. Key Scenario A — Lake Risk

Input

Rainfall          38.2 mm/h
Lake Water Level  82 cm
IRR01             RUNNING
DP01              STANDBY

Deterministic Events

HEAVY_RAINFALL
HIGH_WATER_LEVEL
IRRIGATION_ACTIVE

Incident

WEATHER_RELATED_LAKE_RISK

AI Context Retrieval

AI 查詢：

Lake Zone devices
IRR01 capability
IRR01 current state
DP01 current state
Recent Observation history

取得：

IRR01 capability = STOP
IRR01 state      = RUNNING
DP01 state       = STANDBY

Structured Analysis

事件證據：

建築脈絡：

Recommendation

Pause IRR01 Irrigation

可執行依據：

Human Approval

管理者核准後執行：

IRR01
RUNNING → STOPPED

Feedback

設備狀態變化產生：

OBS-036
IRR01.status = STOPPED

OBS-036 再回到 Observation pipeline。

9. Scenario B — HVAC / Energy / Occupancy

第二個情境用於驗證同一套架構是否可以跨 domain 使用。

Input

Outdoor temperature  27°C
Occupancy            LOW
AHU03 power          92 kW
Building energy      186 kW

系統將 HVAC、Energy、Occupancy 與 Weather 資料整合後，形成值得進一步調查的 Incident。

AI 可以提出：

但不能直接宣稱：

AHU03 已故障。

因為目前 evidence 只能支持「值得調查」，不足以支持「設備故障」這個事實判定。

10. Negative Scenarios

Prototype 不只驗證「何時應該產生 Incident」，也驗證「何時應該保持安靜」。

Negative C — Heavy Rain Only

Rainfall = 38.2 mm/h
Lake water level = 58 cm

預期：

不建立 Lake Risk Incident

因為只有單一強降雨訊號，沒有足夠的跨系統 evidence。

Negative D — Legitimate HVAC Load

Outdoor temperature = 35°C
Occupancy = HIGH
HVAC load = HIGH

預期：

不直接判定 HVAC anomaly

因為高外溫與高 occupancy 可以合理解釋較高的 HVAC load。

11. AI Role & Guardrails

AI 負責

AI 不負責

Design Principle

AI can enrich the source of truth, but cannot overwrite it.

12. Persistence & Auditability

系統分層保存：

Observation

原始事實。

Event

deterministic rule output。

Incident

cross-system correlation result。

Analysis

AI inference，保留 evidence reference。

Action

包含 recommendation、human approval、execution result。

Feedback

保存人工確認與實際結果。

因此若 AI 判斷錯誤，系統仍可保留：

而不污染 source of truth。

13. MVP Scope

In Scope

Non-Goals

本 Prototype 不做：

14. MVP Success Criteria

本 Prototype 完成的標準不是功能數量，而是能完整展示一條 vertical slice：

3+ Subsystems
↓
Telemetry
↓
Normalized Observation
↓
Deterministic Events
↓
Cross-System Incident
↓
AI retrieves Building Context
↓
Evidence-backed Analysis
↓
Device-specific Recommendation
↓
Human Approval
↓
Action
↓
New Observation

並額外展示：

15. Risks & Assumptions

Synthetic Data

本 Prototype 未取得真實智慧建築 telemetry，因此所有 scenario data、threshold 與 device identifier 皆為 synthetic。

Domain Assumption

Prototype 以公開案例作為研究起點，用於驗證系統設計思路，不代表真實建築現場流程或任何公司的實際架構。

Building Metadata Quality

本 Prototype 假設 Building Context 已是一份乾淨、完整且可查詢的關係圖。真實專案中這份資料來自既有的 BIM / IFC 模型與 BMS point list，但品質落差是主要風險：BMS point 屬性各廠商格式不一、關係常未編碼在命名規則中，部分場域甚至沒有可用的 point name。

目前業界以 regex 比對、語法分群與 LLM 輔助分類等方式做半自動對映，仍需大量人工驗證。因此在真實導入中，建立與維護這份關係圖本身就是一個需要編列時程與人力的工作項目，而非既有資料的附帶產物。

AI Limitation

AI output 為 decision support，而非安全關鍵設備的自動控制依據。

在真實 production environment 中，仍需要：

16. Closing Note

這個 Prototype 的目的不是在短時間內重新打造一套完整智慧建築平台。

我更希望驗證的是：

面對一個原本陌生的智慧建築 domain，是否能快速理解問題、拆出資料層與系統邊界，建立可執行的 backend architecture，並判斷 AI 適合介入的位置與不應跨越的邊界。

因此，我將重點放在：

這六項的共同點是：即使 AI 的判斷是錯的，系統仍然保留了足以被檢查、回溯與接手的完整紀錄 —— 原始 Observation、規則判定、當時引用的脈絡、AI 的建議與人工的決定分層保存，且彼此都指得回去。