SYSTEM ARCHITECTURE · 設計建議

FM 平台系統架構圖

每 site 獨立部署前端，共用一個中央 Supabase／Postgres 數據平面；現場數據經 Site Gateway 統一收斂為 canonical JSON 先寫入雲端，admin 前端可以直接管理設備，SQL import 全程留痕。

現場 / 站點層 — 每個 site 獨立部署一套 雲端 — 中央 Supabase（共用一組資料庫，RLS 按 site_id 隔離） MQTT 感應器 溫濕度 · 能耗 · 設備狀態 pub/sub → Site Gateway BMS · BACnet/IP 建築管理系統 Points 輪詢 → Site Gateway 供應商系統 冷氣 / 電力 / 消防承辦商 SOAP 接口 → Site Gateway 就地收斂 原始協議唔出站點 統一轉 canonical JSON 先上雲 Site Gateway · 站點閘道 MQTT Broker 訂閱 sensor topics 保留 / 重連 / QoS BACnet Adapter 輪詢 BACnet Points 點表映射 SOAP Adapter 呼叫承辦商 Web Service 錯誤重試 / 超時 Normalize 統一 Canonical JSON 加 site_id · timestamp canonical JSON · service role 寫入 中央 Supabase · Postgres（共用實例） Postgres RLS · site_id 隔離 Auth 登入 · 角色 · JWT PostgREST REST API Equipment CRUD 前端 admin 直接增減 SQL Import trigger 填 updated_by Audit Log 操作審計 · 全面留痕 Site Web App 每 site 獨立部署前端 · 登入後按角色顯示 · admin 直接 CRUD 設備 Root Console 監控中心 · 統一總覽 · 跨站告警 / KPI · 唯讀（monitor-only） REST JWT select 唯讀 數據流向 唯讀 / 管理請求 部署邊界 MQTT 來源 BACnet 來源 SOAP 來源

數據流

  1. 現場設備（MQTT 感應器、BMS BACnet Points、供應商 SOAP）以原生協議將數據送到 Site Gateway。
  2. Site Gateway 用三個 adapter 收斂各協議，再經 Normalize 統一成 canonical telemetry JSON（補上 site_id 同 timestamp）。
  3. Gateway 用 service role 加密將數據寫入中央 Supabase 嘅 telemetry 表。
  4. 每個 site 嘅 Web App（獨立部署）經 PostgREST 讀寫自己 site 嘅數據 —— RLS 按 site_id 自動隔離，前端唔會互相睇到。
  5. Admin 喺前端直接增減 equipment，或者 SQL import；兩者都經 trigger 填 updated_by / updated_at 並寫入 audit_log。Root Console 只讀跨站總覽。

核心設計決定

中央單一資料庫

唔使每個 site 起一套 Supabase。一個 Postgres project 加 RLS（site_id 政策）就做到多租戶隔離，慳成本又方便統一升級；前端先係每 site 獨立 deploy。

站點閘道就地收斂

Postgres 唔會直接掂 BACnet 或 MQTT。Site Gateway 負責協議轉換同 normalize，後端同報表永遠見到統一格式，加新數據源只係加 adapter。

SQL import 有得留痕

equipment 嘅 insert / update 由 trigger 自動填 updated_by / updated_at，同時寫入 audit_log —— 無論前端 admin 直接改定係 SQL import 都唔會漏。

呢個係建議架構。想睇某一層嘅細項（例如 RLS 政策 SQL、Gateway 部屬方式、或者 telemetry 表 schema）可以直接話我知。