互通性與標準碎片化，通訊協定多頭馬車、跨品牌與系統整合困難。
生命週期像甲蟲：埋在地下數年，一羽化，過沒多久就掛了。

課程地圖

1-0 先面對五個物聯網現場痛點

括號內是後續主要對應章節，先知道問題會被拆到哪裡，不需要在這裡一次看完所有名詞。

還有一個現實點要先講清楚：
IoT 常常不是一路線性成長，
而是反覆被綠能、節能、數據、AI、法規、補助、ESG 這些議題重新炒熱。
景氣好、政策在推，資源就流進來；世界有事、預算收緊，很多案子又先等等。

但現場問題不會因為市場冷掉就消失。
設備還是會換，網路還是會斷，資料還是要追，報表還是會被質疑。

更麻煩的是，IoT 問題不只技術，也不只世界趨勢。
客戶越依賴廠商工班，現場維修人員的流失和交接就越貴。
留不住現場員工，場域經驗交接不了，客戶也會慢慢流失。

所以系統要盡量讓現場人員有好流程處理問題，
也要讓客戶能做基本維護。
操作越簡單、越直觀，越能降低使用難度和交接成本。

法規、世界趨勢還有員工心態，我們沒辦法直接由系統設計解決，
但我們可以設計一個相對較彈性的架構，減輕開發、維護的負擔，
再配合商業模式跟教育訓練，來達到共贏的結果。

這邊介紹的設計架構，叫 LocalNest，
不能百分之百解決所有案場問題，也不是替所有案場定一套唯一 SOP。
LocalNest 的設計前提，
是盡量把多廠牌感測器、上雲安全考量、多通訊協定、維護成本和交接問題，
拆成比較容易設定、追查和維護的系統責任。

1-1 先對齊基礎：這章討論的是哪一種 IoT 架構

IoT 架構不是只有一種。量測裝置可能直接上雲，
也可能透過 PLC、工業電腦、邊緣主機、第三方閘道器或接收器進入後端系統。

這裡先採用有接收器的架構來說明。
這裡的量測裝置代表現場感測器、電表、震動計、漏水偵測器等資料來源；
接收器代表靠近現場、先把資料收進來，再送往伺服器的設備或程式。

選這條主線，是因為它能把資料進站、離線暫存、補傳、接收來源身份和伺服器資料整理等問題拆得最清楚。

現場通常也不是一顆量測裝置對一台伺服器。比較常見的是多個量測來源先匯入接收器，由接收器整理後再送往本地伺服器。

至於沒有接收器的架構，例如 PLC、工業電腦、第三方閘道器、既有系統或外部程式直接送資料，只要能整理成伺服器需要的 JSON 資料格式，後面的解析、資料可信度、歷史資料與報表流程仍然可以接續。這部分放到額外章節說明，第一章先不展開。

1-2 本章先看資料流邊界

圖解：資料轉送流程

如果案子會遇到：

• 網路不穩。

• 裝置會換。

• 報表要追。

• 客戶要看歷史資料。

• 系統不能完全依賴某一位工程師。

• 同一套架構未來可能接不同協議或多個廠區。

那這章後面談的問題就會開始出現。

1-3 現場痛點：查得到，不代表系統真的穩

許多團隊第一次接觸 IoT 專案，直覺是：

讓應用程式可以查到量測裝置數值就好了。

這個想法不是錯，但它太晚才開始看問題。

查得到資料，只代表資料已經整理到某個出口。在這個出口之前，可能還有一大段看不見的現場問題：

圖解：流程圖

不是每個系統都會長得一模一樣。
有些裝置直接上雲，有些經過接收器，有些從 PLC 或工業電腦來。

但只要處理的是現場資料，就會遇到同一個核心問題：

查到的數字，只是最後呈現出來的結果。
真正麻煩的是前面那段資料怎麼來、缺了怎麼辦、能不能相信、以後還能不能追。

現場通常也不是一顆量測裝置對一台伺服器。
一條生產線可能同時掛著三十個溫度計、六個電表、四個震動量測裝置，通訊協議可能混用 BLE、Modbus、Wi-Fi、Zigbee、LoRa，甚至還有廠商自己的格式。這裡的 Modbus 是工業設備常用的請求／回應式通訊協定，可以透過序列線路或 TCP/IP 網路讀寫設備資料；CH07 與 EX04 會再展開接收器和點位設定。

系統整合商要把這些異質裝置的訊號收進來、整理成統一格式、判斷資料是否可信，最後才讓應用程式或報表看到有意義的數值。

而且成本通常不是一次看得出來。規格書上會寫低功耗、精準量測、穩定傳輸，但這三件事在現場常常互相拉扯：省電會影響傳輸頻率，傳輸穩定需要更好的接收環境，精準量測又需要校正與維護。產品設計沒有把這些成本算進去，後面就會變成維修人員、工程師和客服一起補洞。

1-4 一筆資料要有效，中間其實有好幾段不能斷

一筆資料要成功進到伺服器，不是只有量測裝置有量到就好。中間任何一段斷掉，最後結果都可能變成：伺服器沒有收到有效資料。

以一個常見的現場架構來看，一筆資料至少會經過這幾段：

圖解：流程圖

每一段都可能出問題。

1. 量測裝置要有電，才能正常作業

最前面的量測裝置本身要先活著。

它可能遇到：

• 電池沒電。

• 外部供電斷掉。

• 接頭鬆脫。

• 量測裝置故障。

• 量測裝置被拆掉。

• 現場人員移動量測裝置。

這種情況不是資料晚到，而是資料源頭本身就可能沒有正常工作。

2. 量測裝置的通訊要通，資料才送得出來

量測裝置有電，不代表資料送得出來。

這裡的網路要用廣義理解，不只是乙太網路，也包含 BLE、Wi-Fi、Zigbee、LoRa、RS-485 / Modbus、有線網路和廠商自己的通訊方式。

量測裝置可能有正常量測，但資料送不出去。例如 BLE 訊號被金屬機台干擾、Wi-Fi 訊號不穩、RS-485 線路接觸不良、Modbus 輪詢 timeout、LoRa 訊號弱，或裝置離接收器太遠。

這時候現場可能會出現一種很麻煩的情況：

量測裝置其實還活著，但伺服器看不到資料。

3. 接收器要有電，才能收資料

很多現場不一定是裝置直接上雲。中間可能會有接收器、PLC、工業電腦、邊緣主機或資料採集程式。

這些東西如果沒電、當機、服務停掉，量測裝置就算正常送資料，也沒有人接。

所以資料缺失不一定是量測裝置的問題，也可能是中間接收器掛了。

4. 接收器的網路要通，資料才進得了伺服器

接收器收到資料後，還要能把資料送到伺服器。

這一段也可能斷：接收器到伺服器的網路斷線、工業電腦網卡異常、防火牆擋住、VPN 斷線、資料傳輸服務連不上、本地網路交換器異常，或 IP 設定被改掉。

這種情況下，接收器可能有收到資料，但伺服器沒收到。如果接收器有暫存機制，之後還可能補回來；如果沒有暫存，這段資料就真的消失了。

5. 伺服器要有電，服務才有地方接資料

伺服器本身也不是永遠正常。

它可能遇到主機斷電、作業系統當機、磁碟滿了、服務沒啟動、程式 crash、排程沒有跑、資料夾權限錯誤。

如果伺服器掛了，前面資料再正常也沒用。這也是為什麼 IoT 系統不能只想量測裝置怎麼送資料，還要想：

伺服器長期跑起來後，怎麼檢查、怎麼修、怎麼交接。

6. 伺服器的網路要通，使用者才看得到資料

有時候資料其實已經進伺服器了，但應用程式或雲端入口看不到。

原因可能是伺服器對外網路斷線、應用程式查詢 API 失敗、內網名稱或 IP 設定錯誤、Cloud relay 斷線、權限或存取憑證過期、防火牆規則變更。

這時候現場資料可能沒有消失，但使用者端會覺得：

系統是不是壞了？

所以 IoT 系統要分清楚：

• 是資料源頭沒有資料？

• 是中間通訊斷掉？

• 是伺服器沒收到？

• 是伺服器收到了，但使用者查不到？

這些在維護上的意義完全不同。

1-5 缺資料不能用 0 假裝沒事

很多系統遇到資料缺口時，會直接補 0。

這看起來方便，因為資料表很整齊，圖表也不會斷線。但在工廠現場，0 常常是一個危險的謊言。

溫度是 0°C，可能是冷藏量測裝置真的在 0°C；也可能是量測裝置沒有資料，被系統補成 0。

電流是 0A，可能是量測裝置真的停機；也可能是資料沒有到。

這兩種情況在維護上的意義完全不同。

所以第一個重要原則是：

缺資料要被標記，不要被偽裝成正常數值。

錯誤做法：

圖解：流程圖

比較合理的做法：

圖解：流程圖

在這套課程後面要拆解的系統設計裡，空值本身就是資訊。它告訴系統：

這個時間點沒有收到有效資料。

這個資訊後面會影響資料可信度、報表計算、告警策略和離線補償。

1-6 部分可信，比在線 / 離線更接近現實

傳統監控系統喜歡把量測裝置分成在線和離線。

這對單一量測裝置還勉強能用，但對複合裝置很快就不夠。

例如一台三相電表，底下其實有三個電流量測裝置。

今天：

程式碼區塊 CODE-001（在 Teachify 請使用原生程式碼區塊）

R 相正常
S 相正常
T 相斷線

這台電表算在線還是離線？

說在線，資料明顯不完整。說離線，剩下兩相的資料又被浪費掉。

所以更接近現實的做法，不是只問：

這台量測裝置在線嗎？

而是問：

這份資料現在有幾成可信？

後面課程會用資料可信度分數來描述這種灰度狀態。正式名稱和公式會留到 Part 3。

這一章先不用看公式，只要知道它解決的是同一個問題：

有些資料不是全好，也不是全壞，而是部分可信。

1-7 非技術類影響因素

真正讓 IoT 專案可能失敗的原因，通常不是技術做不出來。

而是做完之後：

• 誰來維護？

• 資料放哪裡？

• 出了問題誰負責？

• 量測裝置換掉後，歷史資料怎麼辦？

• 報表數字被質疑時，要怎麼追？

• 工程師離職後，下一個人看不看得懂？

• 多廠、多線、多角色以後，資料可見範圍怎麼控？

很多工廠的知識也不在文件裡，而在人腦裡。

誰要先做。哪個數字怪怪的先不要動。哪台量測裝置雖然亮紅燈但其實還可以撐。哪個量測裝置常常飄，但老員工知道它不是壞掉。

要把這些知識變成資料、規則和系統設計，阻力不只是技術問題，也是責任和習慣問題。

更現實的問題：

當量測裝置變多、資料變亂、工程師交接、客戶開始追報表時，這套系統還能不能被維護下去。

後面章節會慢慢拆解 IoT 伺服器怎麼處理：

• 裝置身份。

• 資料採集。

• 資料可信度。

• 歷史資料。

• 離線補傳。

• 應用程式查詢。

• 多站擴充。

• 現場設定與產品化邊界。

1-8 回到架構責任：先選責任，再選實作方式

看完前面的痛點，接下來不是照抄某一套程式碼，而是先分清楚一套現場型 IoT 系統應該有哪些責任邊界。

接收器要負責什麼、伺服器要負責什麼、身份怎麼分層、資料怎麼變成有語意的值、歷史資料怎麼整理、帳號和多站資料怎麼控制可見範圍，這些是架構問題。

至於最後用 Python、C#、Go、MCU、樹莓派、CSV、JSON、SQLite、Web 後台、UART 或 SD 卡來實作，都是產品設計選擇。架構責任先想清楚，實作方式才有判斷基準。

真正要怕的是這件事：

IoT 系統真正可怕的地方，不是做不出來，而是 POC 後，甚至第二年以後，還能不能維護。

很多案子第一版看起來都能跑。資料有進來，儀表板有畫面，API 也查得到數字。

但快則 POC 後，慢則 1、2 年以後，問題會慢慢浮出來：

• 量測裝置壞了，要換。

• 現場網路斷了，資料可能缺一段。

• 客戶問報表為什麼怪怪的。

• 工程師離職，沒人敢改。

• 新增一個品牌的量測裝置，又要重寫資料解析程式。

• 多一個廠區或多一台 LocalNest，APP 不知道該查哪裡。

• 當初為了趕示範寫死的邏輯，開始變成技術債。

這些問題不是理論，而是 IoT 專案後續很容易回到團隊身上的售後成本。

本章判斷重點

1. 第一筆資料上線，不代表系統成功：POC 後的維護、追查、交接和擴充，才是 IoT 伺服器的真正壓力。

2. 碎片化會一路放大：不同裝置、不同協議、不同資料格式、不同廠區與不同角色，都會讓系統從 Demo 變成長期維護問題。

3. 隱形成本會慢慢浮出來：省電、精準、傳輸穩定都不是免費要求，最後會落到換電池、校正、修網路和維護人力。

4. API 查得到，不代表系統真的穩：API 前面通常還有一整條資料管線要維持資料完整性。

5. 先判斷 IoT 架構類型：裝置直上雲、現場接收器、本地伺服器、PLC，都會影響後面的設計。

6. 缺資料要被標記，不要用 0 假裝沒事：0 是數值，空值是狀態，兩者不能混用。

7. 部分可信比在線 / 離線更接近現實：複合裝置特別需要灰度判斷。

8. 產品生命週期不能都耗在蟲蛹期：系統產品可能只有 2~3 年生命，前期導入與穩定卻吃掉一半以上，甚至 8~9 成；第二年維護費能不能說清楚，才是 IoT 系統能不能長期走下去的壓力。

課程權利與範例授權
© 2026 馬蹄刃有限公司。作者／主講：臭G蛋。課程文字、圖表與教學編排不得全部或實質重製後販售；本課程明確標示之範例程式與設定檔可自由使用、修改、整合、部署及商業化。