Collector 與 Static 輸入
設備輪詢與 static / virtual 點位輸出，已拆成原生路徑，不再全部塞在原廠黑箱裡。
降低原廠綁定
掌握 SCADA 執行核心。掌握自己的原始碼。
這套 QScada2 部署是舊版 IOTBI runtime 的原生替換路線。
設備輪詢、靜態資料發送、歷史寫入、最新值、告警、腳本、排程、
對外推送與頁面設定，正在逐步拉回到我們自己可控的原始碼內。
批次化 history writer 持續優化中
原生 static / virtual device runtime
HMI 頁面 schema 已納入 /api/configs
目前原生範圍
開發中
8+
執行模組
1
自有後端主幹
API
原生 CRUD 與健康檢查
HMI
原生頁面設定
Collector Runtime
輪詢、在線狀態、手動刷新、設備快取
原生
History 與 Latest Writer
即時資料寫入歷史表與最新值儲存
原生
Static Runtime 與 Alarm Engine
靜態點位、告警判斷、衍生資料流
原生
Configurator 與儲存頁面
原生編輯器 schema 已透過 /api/configs 管理
原生
原生模組
執行核心正重構為可獨立運作的服務。
不再依賴原廠黑箱內核，平台正改為清楚、可測試、可觀測的模組，
每個模組都有自己的 queue、metrics 與控制面。
History 與 Realtime Writer
歷史寫入與最新值寫入已分離，backlog、drop policy、queue 壓力可各自控制與觀測。
Alarm、Script 與 Schedule 流程
告警判斷、腳本執行、排程動作已拆成獨立服務，具備可直接檢視的 runtime 狀態與控制 API。
替換進度
目標不是補丁式修 IOTBI，而是做出我們自己的可控系統。
sidecar guard 與外部保護措施可以先止血，但長期方向仍是替換掉造成 queue 延遲、
stale history replay 與模組互相阻塞的原生 runtime 路徑。
已知瓶頸
History writer backlog 與 stale replay
我們自己的實作方向是把 realtime update 與 history persistence 分開，
補上 batching、queue metrics 與 backlog policy，不再讓黑箱 writer 自己漂移。
批次寫入
Queue 指標
過期資料 drop / coalesce
已知風險
原廠內部 runtime 互相耦合
Collector、alarm、history、static、script、push 正逐步拆成原生模組，
避免單一路徑塞住時拖垮其他流程。
清楚模組邊界
明確狀態 API
獨立控制
部署模式
邊緣採集、資料庫節點與操作介面可以分開演進。
預期的運作模式支援靠近設備端的本地採集、可控的資料庫持久化、
可設定的對外路由，以及後續雲端擴充，而不再把原廠 runtime 當成核心依賴。
營運後台
設備、點位、告警、排程、推播目標、runtime 健康狀態與 HMI 頁面，都可在同一套登入後台管理。
對外連接與雲端路徑
對外 connector 與未來多租戶資料聚合，可用原生服務方式實作，不必再繞原廠 writer 的限制。
可延伸的原始碼基底
因為原始碼掌握在自己手上，history batching、viewer 頁面、設備寫入控制、租戶政策都能自行擴充。
先把現有堆疊跑穩，再持續替換剩餘的原廠核心。
目前後台已經能看到原生 runtime 模組與頁面編輯器。接下來會持續把系統 從不透明的原廠內部 writer，移到我們自己可測試、可分析、可交付的模組上。