ThingsBoard 是什麼？從 ESP32、PLC 資料接入到 Alarm、Dashboard 與 SCADA 完整介紹

ThingsBoard 能把分散的 IoT 與工業設備資料整合成可管理、可視化、可告警的應用，但它不是 PLC 或安全系統的替代品。本文以工廠冷卻水案例，完整解釋設備接入、資料模型、Rule Engine、Alarm、Dashboard、SCADA、RPC、版本選擇與導入檢核。

工廠裡不缺資料，真正稀缺的是「能讓人及時理解並採取正確行動的脈絡」。液位計有自己的數值，幫浦由 PLC 控制，電表走 Modbus，維修人員又在另一套畫面查告警。當液位持續下降時，團隊往往必須先回答三個問題：是哪一個設備異常？異常已持續多久？誰看過、誰處理、現場是否真的恢復？

ThingsBoard 的價值，就在於把設備連線、資料收集、設備模型、規則、告警與視覺化串成一條可追蹤的資訊鏈。它能改善「資料散落」與「異常難以追查」的問題；但如果把它當成 PLC、安全儀控系統或緊急停機回路，就會跨越不該跨越的工程邊界。

本文不假設讀者熟悉 IoT 平台。接下來會用一套工廠冷卻水循環系統作為貫穿案例，先建立全貌，再深入資料模型、告警狀態、SCADA 與 RPC，最後整理成可執行的導入步驟。

先看結論：ThingsBoard 適合做什麼？不該做什麼？

如果只記得一件事，可以把 ThingsBoard 理解為「位在設備與人員之間的 IoT 應用平台」。它擅長收集跨設備資料、保存時序、管理設備、執行事件規則、建立告警，以及提供遠端監看介面。

對初次導入的企業，較穩妥的起點不是「一次把整座工廠接上線」，而是選一套界線清楚、能量測成效的系統，例如冷卻水、空壓機、能源表計或環境監測。先完成一條從資料進站到告警結案的閉環，再決定是否擴大。

ThingsBoard 在工業 IoT 架構中的位置

ThingsBoard 不是單純的 MQTT Broker，也不是只有圖表的 Dashboard 工具。它把數個原本分散的工作放進同一個應用脈絡：裝置如何被識別、資料屬於誰、規則如何判斷、事件如何升級，以及不同使用者能看到哪些內容。

以冷卻水循環系統為例，可以把資料流想成六個步驟：

1. 液位、流量、溫度與馬達狀態由感測器或 PLC 取得。
2. 原生 IoT 裝置直接上傳，既有工業設備則由 Gateway 讀取與映射。
3. 平台把資料掛到對應的 Device 或 Asset。
4. Rule Engine 依已配置的條件處理訊息。
5. 符合條件時建立或更新 Alarm，必要時再由另外配置的通知規則聯絡人員。
6. 操作人員從 Dashboard 看即時值，工程師用歷史趨勢與事件紀錄追查原因。

這套流程的重點不是讓雲端畫面接管現場，而是建立共用語境。設備、工程師與管理者看到的是同一事件的不同切面，並保留時間與狀態供後續追查。

ESP32、PLC 與儀表資料如何進入平台

路徑一：原生 IoT 裝置直接連線

ESP32 類裝置或具備 IP 通訊能力的控制器，可依裝置端實作，透過 MQTT、HTTP 或 CoAP 發布資料到 ThingsBoard。這條路徑適合原型、獨立感測器與新設計的聯網設備。

「支援協定」不等於接上網路就會自動產生正確資料。裝置端仍需處理身分驗證、金鑰保存、重連、時間戳、資料格式、離線佇列與錯誤回報。正式環境還要決定憑證輪替、停用遺失裝置及韌體更新方式。

路徑二：IoT Gateway 橋接既有工業設備

PLC、電表、變頻器與樓宇設備常已使用 Modbus、OPC UA 或 BACnet。此時可在現場工業電腦或伺服器部署 ThingsBoard IoT Gateway 軟體，由 connector 讀取現場資料，再映射成平台中的裝置與 Telemetry。

Gateway 是軟體角色，不是特定官方硬體，也不是 PLC 的替代品。Modbus 專案仍要確認 unit ID、function code、register 位址、資料型別、byte／word order 與 scaling；OPC UA 則要處理 endpoint、security policy、憑證與 node mapping。RS-485 是實體通訊介面的一種，也不能直接與 Modbus 畫上等號。

企業常在這一步低估「點表治理」。如果同一個流量在 PLC、Gateway 與平台各用不同名稱、單位或倍率，Dashboard 再漂亮也難以信任。建議先建立可版本化的點表，至少記錄來源位址、平台 key、資料型別、工程單位、倍率、合理範圍、更新週期及資料責任人。

先把設備模型建對：Device、Asset 與 Relations

Device：會產生資料或接收命令的裝置

Device 通常代表可連線、發布資料或接收 RPC 的實體或虛擬裝置，例如液位監測器、電表、幫浦狀態模組與 Gateway 所映射出的 PLC 子設備。它不必然是一顆實體感測器，也可能是軟體建立的邏輯裝置。

Asset：描述工廠脈絡的資產

Asset 常用來表示工廠、產線、廠房、機台群組或冷卻水系統。它不是只能收納項目的「資料夾」；Asset 本身也是 entity，可依設計具有 attributes、time-series 或 alarms。

Relations：明確建立有方向的關係

如果要讓平台知道「PLANT-TW01 包含冷卻水系統，冷卻水系統又包含水槽與幫浦」，必須建立有方向的 Relations。平台不會看到幾個相似名稱，就自動推論出正確產線階層。

Relations 的實際價值會在規模擴大後出現。Dashboard 的 entity alias、規則查詢、權限分配與跨場域總覽，都可能依賴這些關係。如果一開始只用命名慣例硬湊，日後搬移設備、共用設備或重整產線時，維護成本會快速升高。

Telemetry 與 Attributes：一個記錄變化，一個描述目前狀態

這兩個名詞是 ThingsBoard 新手最容易混淆的地方。

Telemetry 是帶時間戳的時序資料

Telemetry 可理解為「某個時間點量到什麼」。液位 16.8%、流量 29.6 m³/h、溫度 31.2°C 或馬達電流，都適合成為 time-series。它可以查詢歷史、畫趨勢、計算時間窗，也可能由平台規則計算產生，不一定只來自實體感測器。

時間戳品質很重要。若裝置時鐘漂移、Gateway 重送舊資料，或不同來源採樣週期差異過大，圖表看似連續，實際上可能錯置事件順序。導入時應定義採樣頻率、上傳頻率、時間來源、逾時判定與重送策略。

Attributes 保存描述、狀態或設定的最新值

Attributes 是 key-value 形式的屬性，可用來保存型號、位置、韌體版本、設定或告警門檻等最新值與更新時間。依資料由誰維護及誰需要讀取，可使用不同 scope，例如 server-side、shared 或 client-side。

Attributes 不應被描述成自動保留完整變更歷史的 Telemetry。若某個門檻的歷史版本關係到稽核，應另外設計版本紀錄、變更審批或把關鍵變更寫成可追蹤事件。

Rule Engine：把資料轉成事件，但規則必須有人設計

Rule Engine 可對訊息進行過濾、補充資料、轉換與路由，也能配合 alarm rules 或 rule nodes 建立、更新及清除告警。它不會天生知道什麼叫「冷卻水異常」。門檻、持續時間、設備狀態與清除條件，都要根據實際製程配置並驗證。

冷卻水案例可以採用以下「示範邏輯」：液位低於 20%、幫浦仍在運轉，而且條件持續 30 秒，三者同時成立才建立 Critical Alarm。這種設計比單點低於門檻就告警，更能降低液面晃動或短暫通訊雜訊造成的干擾。

但 20% 與 30 秒不是通用安全值。真實門檻要考量槽體有效容積、感測誤差、幫浦抽水率、製程容許時間、正常波動及人員反應時間。若規則會影響營運，至少應用歷史資料回放測試誤報與漏報，並保留規則版本及核准紀錄。

Alarm 不是單一路徑：條件狀態與人員確認要分開

Alarm 至少要分清兩個獨立維度：

• Active／Cleared：異常條件目前是否仍成立。
• Acknowledged／Unacknowledged：事件是否已被人員確認。

因此，告警可能是 Active／Unacknowledged、Active／Acknowledged、Cleared／Unacknowledged 或 Cleared／Acknowledged。工程師按下 Acknowledge，只代表「我已看到或接手」，不代表液位已恢復；告警轉為 Cleared，也只表示設定的清除條件成立，不代表維修、上鎖掛牌、驗電或文件結案全部完成。

通知同樣不是建立 Alarm 後自然發生。通知規則、收件對象與 channel 需要另外設定及測試。正式上線前，應驗證建立、升級、確認、清除與重複發生的處理方式，並測試夜間、假日、收件者無回應及通知管道故障時的替代流程。

Dashboard：把即時值、歷史與告警放在同一個工作畫面

Dashboard 的任務不是塞入最多圖表，而是幫助特定角色回答當下問題。操作人員可能先看液位、流量、幫浦狀態與未確認告警；維修工程師需要歷史趨勢、事件時間與設備資訊；管理者則關心跨產線比較及長期異常。

上圖是 ThingsBoard Community Edition 4.3.1.3 的真實 Demo 介面，僅代表該本機示範版本與資料集，不應解讀為目前最新版，也不證明所有版本、權限設定或部署都會呈現相同功能與版面。

資料可見範圍可依 tenant、customer、user、entity assignment 與實際權限設定來限制。企業不應只靠「不同網址」或「不同 Dashboard 名稱」隔離資料，而要用測試帳號逐一驗證：該角色能列出哪些 entity、開啟哪些 Dashboard、查看哪些告警，以及是否具備任何寫入或 RPC 權限。PE 的進階權限能力也不宜直接泛化為 CE 具有完全相同的角色模型。

SCADA Dashboard：先確認你使用的是哪個版本

ThingsBoard Professional Edition 與 ThingsBoard Cloud 的功能脈絡中，提供 SCADA Dashboard 與 SVG-based SCADA Symbols。這類畫面可用固定欄格位置的 layout 放置水槽、幫浦、閥門與管線，Symbol 則可依 behavior 設定讀取 Telemetry、Attributes 或 Alarm 狀態，也可設定 Popup、Dashboard state 或其他 action。

這裡有一條重要版本界線：不要把 PE／Cloud 的 SCADA 功能說成 Community Edition 4.3.1.3 的標準介面。 如果文章、簡報或驗收畫面同時出現 CE Dashboard 與 PE／Cloud SCADA，必須清楚標出各自來源，不能混剪後統稱為 CE。

即使 Symbol 會變色，也不能只靠畫面顏色證明現場異常。可稽核的展示應同時對應真實資料 key、時間戳、告警紀錄與 behavior 設定。若資料來自 Demo，也應明確標示，避免把後製動畫誤認為產品已完成綁定。

RPC 可以送命令，但「成功」至少有三層

RPC，也就是遠端程序呼叫，可讓平台向裝置送出命令。它適合經過授權的操作，例如要求測試裝置回報狀態、更新非安全設定，或在完整風險控制下執行遠端動作。

工程上必須把以下三層分開：

1. 命令已送出：平台已嘗試傳送 RPC。
2. 裝置已收受或回覆：裝置端應用程式收到命令，two-way RPC 可能回傳 response。
3. 現場狀態由 Telemetry 回證：獨立量測或狀態回授顯示設備確實到達預期狀態。

One-way RPC 得到平台端成功回應，不能證明幫浦已啟動；裝置回覆「OK」，也可能只代表程式接受要求。即使 Telemetry 顯示目標狀態，仍不等於安全條件、機械到位、流程許可與人員防護全部成立。若是閥門動作，可能還要比對限位、壓力或流量；若是馬達，可能要檢查接觸器回授、電流與製程條件。

因此，三層回證是降低誤判的基本資訊設計，不是功能安全保證。ThingsBoard RPC 不應承擔 E-stop、安全聯鎖、SIS、Safety PLC 或確定性即時閉迴路控制。

ThingsBoard 與 PLC、HMI、SCADA、MES 的責任分工

PLC、DCS 與現場 HMI

PLC 或 DCS 負責確定性即時邏輯、設備控制與閉迴路；現場 HMI 則讓操作人員在機台附近監看與操作。是否可被遠端平台替代，必須依製程、可用性、網路失效模式與操作程序評估，不能只因 ThingsBoard 也能顯示按鈕就直接取代。

Safety PLC、SIS 與 E-stop

Safety PLC、SIS、安全聯鎖與實體 E-stop 承擔人員與設備的安全功能，應維持經設計、驗證且獨立的安全鏈。ThingsBoard 不應被宣稱具有 SIL 能力，也不能把平板上的軟體按鈕當成緊急停機。

傳統 SCADA 與 ThingsBoard

ThingsBoard 可提供類 SCADA 的監控、歷史、告警及授權操作能力；PE／Cloud 還有專門的 SCADA Dashboard 功能。不過，能否取代既有 SCADA，取決於通訊驅動、冗餘、離線操作、稽核、工程工具、維運能力、法規與現場需求。較務實的做法，常是先由 ThingsBoard 承接跨設備與跨場域資料，再決定哪些舊系統功能值得整併。

MES

MES 著重工單、排程、品質、追溯與製造執行。ThingsBoard 可以提供設備狀態、能源與告警資料給 MES，卻不會因為有 Device、Rule Engine 與 Dashboard，就自動具備完整 MES 流程。

CE、PE、Cloud 與 Edge 該怎麼選？

部署選項可先分成中央平台與遠端站點兩個問題。

• Community Edition（CE）：免費開源，適合自行部署與自行管理。
• Professional Edition（PE）：商業版，可自行管理，功能與授權應依實際需求確認。
• ThingsBoard Cloud：官方代管的 PE 服務，適合不想自行維運中央平台基礎設施的團隊。
• ThingsBoard Edge：部署在遠端站點的獨立 edge 產品，分為 Edge CE 與 Edge PE；它不是與 CE、PE、Cloud 對等的「第四種 edition」。

Edge 必須與中央 Server edition 相符：Edge CE 對應 CE Server，Edge PE 對應 PE Server 或 Cloud。Edge 是軟體，不包含工業電腦硬體。離線期間能保留哪些本地功能、資料如何儲存、復線後如何同步，以及是否可能因容量或設定造成資料缺口，都要用實際版本與環境測試，不能把「有 Edge」寫成任何 WAN 中斷都零資料遺失的保證。

選擇時不只比較授權費。還要把主機、資料庫、備份、監控、升級、資安修補、憑證、維運人力、資料保留與災難復原納入總成本。PoC 可以從單機開始，正式環境仍要依資料率、裝置數、保留期、查詢負載與可用性目標進行容量規劃。

企業導入的八步檢核表

1. 先定義決策問題

不要從「要做哪些圖表」開始。先寫清楚誰要在多久內知道什麼、採取何種行動，以及如何證明處置有效。例如：「液位持續偏低時，值班工程師在五分鐘內收到可判讀的告警，並能從趨勢確認異常起點。」

2. 選一個可隔離的 PoC

挑選不涉及安全控制、資料來源清楚且能重現異常的系統。先在測試設備或影子資料上驗證，避免初期 RPC 直接操作生產設備。

3. 建立設備與點表契約

定義 Device、Asset、Relations、Telemetry key、Attributes scope、單位、時間戳與命名規範。同步指定資料擁有者及變更程序。

4. 驗證資料品質與失效狀態

測試斷線、重連、重送、亂序、重複值、感測器卡值、超出合理範圍及時鐘偏移。Dashboard 應能顯示資料新鮮度，而不是把最後一次數值永遠當成目前狀態。

5. 用歷史資料驗證規則

回放正常波動與已知異常，觀察規則是否誤報或漏報。門檻、延遲、抑制、嚴重度與 clear condition 都要留下版本。

6. 把告警流程當成營運流程

驗證收件者、值班表、升級、Acknowledge、處置註記與結案責任。通知測試不能只看平台是否建立 Alarm，還要確認 channel 真的送達核可對象。

7. 對 RPC 採最小權限

預設只讀。需要遠端命令時，限制帳號、裝置、method、參數範圍與操作情境，保留稽核紀錄，並設計裝置回覆及獨立 Telemetry 回證。所有安全功能仍留在現場安全鏈。

8. 驗收後再擴大

用可量化指標判斷 PoC：資料完整率、告警延遲、誤報率、平均確認時間、平均處置時間，以及斷線復原結果。通過後才複製到其他設備，並把備份、HA、升級與資安納入正式維運。

常見誤區

「資料有進來，就表示整合完成」

資料能顯示只證明最短路徑成立。單位、倍率、時間戳、資料新鮮度、設備身分與錯誤狀態若未驗證，後續規則可能建立在錯誤輸入上。

「Acknowledge 就代表問題解決」

Acknowledge 是人員確認維度；Active／Cleared 才描述條件是否仍成立。現場工單是否完成，又是另一套營運證據。

「RPC 回覆成功，就能放心做遠端控制」

回覆只到應用層。現場動作、製程結果與安全狀態需要各自的回證與程序。網路平台不能取代硬接線安全功能。

「Edge 是第四種版本，裝上就不怕斷網」

Edge 是遠端站點產品，仍分 CE／PE 並受中央 edition 相容性限制。離線行為與同步結果必須實測，還要規劃儲存容量與故障恢復。

結論：先建立可信任的資料閉環，再談全面整合

ThingsBoard 能讓企業從分散設備中建立共同的資料與事件脈絡：裝置有一致身分，資料有時間軸，規則有版本，告警有人確認，Dashboard 能回看歷史。這些能力對能源管理、設備監測、遠端維運與跨場域管理都很有價值。

它的成熟用法，不是把所有現場控制搬到瀏覽器，而是讓每一層做自己擅長的事。PLC、DCS、Safety PLC、SIS 與 E-stop 守住即時控制與安全；ThingsBoard 負責跨設備資料、歷史、告警與授權協調；MES 延續製造執行。當責任邊界清楚，平台整合才會從展示專案變成可長期維運的系統。

用一條可驗證的流程開始 ThingsBoard PoC

如果你正評估 ThingsBoard，先不要從「要買哪個版本」開始。請帶著一個具體場景，整理五項資料：現有設備與協定、每秒資料量、希望偵測的事件、通知與處置責任、禁止被平台承擔的安全功能。

下一步建議：安排一場架構盤點，選定一套非安全關鍵設備，完成「接入 → 建模 → 規則 → Alarm → Dashboard → 人員處置 → Telemetry 回證」的測試閉環。需要跨廠區、進階權限、PE／Cloud SCADA 或 Edge 時，再依實測結果規劃版本、資安與維運架構。

台灣智能感測科技有限公司長期關注 ESP32、MQTT、RS485／Modbus、Home Assistant、ThingsBoard、PLC 與工業資料整合。如需評估設備接入、資料點表、Dashboard、Alarm 或 PoC 架構，可先整理現場協定、資料量、告警需求與安全邊界，再進行技術盤點。