公司要你評估導入或自建物聯網伺服器，該怎麼規劃？
當公司要導入或自行開發物聯網系統，工程師接到「評估一套物聯網伺服器該怎麼規劃」的任務時，通常不會只有寫一支接收資料的程式這麼單純。
資料從哪裡來、怎麼傳輸、要在哪裡處理，以及最後要提供哪些功能，都會影響整體系統的設計。
在分工較完整的公司裡，這些內容可能需要和硬體、韌體、控制、網路、廠務、資訊或設備廠商共同討論；但在中小企業裡，也可能直接由同一位工程師負責大部分的規劃與實作。
不論實際分工如何，接到物聯網伺服器的規劃任務時，可以先從以下兩個動作開始：
- 釐清收到的資料要拿來做什麼
- 設計資料的架構與路徑
■釐清收到的資料要拿來做什麼
不同的資料用途，會直接決定伺服器需要開發哪些程式。
這裡不是要工程師重新評估導入物聯網對公司有沒有商業效益， 而是要把公司提出的目的，轉換成可以實作的軟體功能。
1. 判斷是否超過某個數值
例如：
- 溫度是否超過上限
- 電流是否突然升高
- 壓力是否低於安全範圍
- 設備是否停止運轉
這類用途通常需要開發：
- 條件比較程式
- 警示規則
- 警示紀錄
- 通知系統
- 警示解除或確認機制
警示需要多快產生，也會影響資料的取樣頻率、傳輸頻率，以及判斷程式應該放在現場還是中央伺服器。
2. 查看每週用電分布、溫度變化或設備運轉時間
這類用途通常需要：
- 保存歷史資料
- 進行每小時、每日、每週或每月統計
- 建立報表
- 提供圖表或查詢介面
- 匯出 Excel、CSV 或 PDF
這時除了確認資料收不收得到，也要考慮資料要保存多久，以及大量歷史資料的查詢速度。
3. 分析設備是否出現異常趨勢
例如：
- 溫度持續緩慢上升
- 相同產量下，用電量逐漸增加
- 設備停機次數變得頻繁
- 某項數值開始偏離平常範圍
這類用途可能需要：
- 移動平均
- 趨勢比較
- 基準值比較
- 統計分析
- 異常偵測程式
分析結果是否準確，不只和演算法有關，也和資料量、資料是否缺漏，以及資料本身的可信任程度有關。
4. 預測設備故障、用電量或未來行為
如果要預測未來狀況，可能需要導入AI使用機器學習或神經網路模型，並建立模型推論流程。
取得資料
↓
資料前處理
↓
模型推論
↓
輸出判斷結果
↓
警示、報表或其他系統使用如果模型要在現場即時執行，還要確認 Gateway 或現場主機是否具備足夠的運算能力。
預測準確度同樣會受到資料量、資料品質及資料標記方式影響。
5. 顯示設備目前狀態
例如：
- 設備現在是否運轉
- 目前溫度、電流或轉速
- 哪一台設備已經離線
- 最新一次收到資料的時間
這類用途通常需要：
- 即時資料更新
- 設備狀態管理
- 裝置在線或離線判斷
- 最新資料快取
- 前端查詢介面
畫面需要多快更新，也會影響取樣頻率、傳輸頻率及整體網路架構。
6. 根據資料控制設備
如果系統不只是查看資料，還要根據資料控制設備，就需要額外開發：
- 控制指令
- 操作權限
- 指令傳送紀錄
- 設備回應確認
- 逾時與重試機制
- 操作失敗後的處理方式
控制設備不能只確認「指令已經送出」，還要確認設備是否收到及執行。
7. 把資料提供給其他系統使用
如果資料還要提供給 ERP、MES、能源管理系統、手機 APP、外部平台或其他軟體，就可能需要開發：
- API
- Webhook
- MQTT Topic
- CSV 或 Excel 匯出
- 排程傳送
- 第三方系統串接介面
- 權限與驗證機制
因此，資料最後的使用者不一定只有物聯網系統自己的網頁，也可能是其他內部或外部系統。
■本文從「開始執行」的階段出發
公司導入物聯網系統，大致可能經過以下幾個階段：
- 公司老闆或高層產生導入想法
- 評估導入後對公司有什麼效益
- 決定自行開發、購買現有產品，或採用混合方式
- 開始執行
本文從第四階段出發。此時方向通常已由老闆、主管或其他單位決定，工程師要做的是把既有目的轉換成明確的系統功能，並找出資料格式、程式模組及通訊流程中還沒有被定義的部分。
■設計資料的架構與路徑
確認資料用途後，下一步才是規劃資料要怎麼從現場進入伺服器，經過哪些處理，最後提供給哪一個系統使用。
一條基本的資料路徑可能如下：
感測器／電表／PLC／設備控制器
↓
RS-485／Ethernet／Wi-Fi／BLE／LoRa 等傳輸介面或網路
↓
Modbus RTU／Modbus TCP／BLE Payload／廠商自訂協定
↓
Receiver／Gateway／工業電腦
↓
MQTT／HTTP／TCP
↓
物聯網伺服器
↓
資料檢查與資料庫
↓
警示／報表／AI／API／網頁／APP／其他系統這部分不一定由軟體工程師單獨決定。
開發工程師通常要先提出軟體端的需求，再和硬體、韌體、控制、網路、廠務或設備廠商共同討論。
例如：
- 資料多久內必須送達
- 可以接受多少資料遺失
- 網路中斷時是否仍要運作
- 是否需要離線暫存及補傳
- Gateway 是否需要執行判斷程式
- 是否需要回傳控制指令
- 資料格式由誰定義
- 中央伺服器需要提供哪些介面
如果是在中小企業，以上內容也可能全部落在同一位工程師身上。即使角色重疊，也應該把每一段的功能與責任分開規劃。
1. 決定資料要在哪裡處理
若資料只需要製作歷史報表，通常可以送到中央伺服器後再統一處理。
但如果資料具有以下需求：
- 需要快速反應
- 網路中斷時仍要執行
- 判斷結果會直接控制現場設備
- 原始資料量很大，不適合全部上傳
就要考慮把部分判斷程式放在現場執行。
可以執行程式的位置包括：
- PLC
- MCU 或設備控制器
- Gateway
- 工業電腦
- 現場伺服器
例如：
設備／PLC
↓
Modbus RTU
↓
具備作業系統的 Gateway
↓
執行條件判斷或模型推論
↓
立即產生警示或控制結果
↓
再將資料與結果傳送到中央伺服器如果只是判斷數值是否超過門檻，不一定需要 AI，也不一定需要高效能主機。
若要執行較複雜的資料分析或模型推論， 才需要進一步確認 Gateway 的作業系統、CPU、記憶體及部署方式。
2. 選擇有線或無線傳輸
固定設備、重視穩定性，或要求傳輸延遲較為固定時，可以優先評估有線傳輸。
常見的有線介面或網路包括：
- RS-485
- Ethernet
設備資料再透過對應的通訊協定傳送，例如：
- Modbus RTU
- Modbus TCP
RS-485、Ethernet 是傳輸介面或網路；Modbus RTU、Modbus TCP 則是上層使用的通訊協定，兩者不能混在同一層比較。
但資料具有緊急性，不代表一定只能使用有線，也不能只看到「有線」或「Modbus RTU」就認定傳輸一定比較快。
實際速度與穩定性還會受到以下因素影響：
- 鮑率
- 輪詢週期
- 同一條總線上的設備數量
- 封包長度
- 網路品質
- 重送機制
- 現場是否方便施工
- 設備是否會移動
如果現場不方便拉線、設備會移動，或資料回傳頻率不高，也可以評估 BLE、Wi-Fi、LoRa 或其他無線方式。
軟體工程師主要要提出延遲、頻率、可靠度及斷線處理需求，再與相關人員共同決定通訊方式。
3. 決定伺服器放在哪裡
物聯網伺服器可以放在：
- 公司內部伺服器
- AWS
- Microsoft Azure
- Google Cloud
- 本地與雲端混合架構
選擇時可以考慮：
- 外部網路中斷時，系統是否仍要運作
- 是否需要從公司外部查看資料
- 資料是否允許離開公司
- 是否需要跨廠區集中管理
- 公司是否有人能維護本地伺服器
- 雲端費用是否能長期負擔
- 現場與雲端之間的網路是否穩定
常見的混合架構如下：
現場 Gateway／本地伺服器
負責收資料、即時判斷、暫存及補傳
↓
將需要的資料同步到雲端
↓
雲端負責跨廠區查詢、報表、模型訓練或外部服務因此，伺服器要放在哪裡，不能只看哪一家雲端平台比較方便，而要連同斷線需求、資料安全及後續維護方式一起評估。
4. 定義資料的可信任程度
物聯網伺服器不能只收到一個數值，就直接認為這筆資料一定正確。
至少要能判斷：
- 資料來自哪一台設備
- 資料產生時間
- 伺服器收到資料的時間
- 資料是否延遲
- 是否為離線補傳資料
- 是否重複
- 是否缺漏
- 是否超出合理範圍
- 單位及資料格式是否正確
- 裝置目前是否正常
- 這筆資料是原始值、換算值還是推估值
其中，「沒有收到資料」和「數值為零」是不同的狀態。
數值為零可能代表設備確實沒有運轉；沒有收到資料則可能是感測器、通訊、Gateway 或伺服器發生問題。
後面的警示、報表、分析及 AI 都建立在這些資料上。如果系統無法區分正常、延遲、缺漏及補傳資料，後面的判斷結果就很難被信任。
5. 保持模組的獨立性與可維護性
物聯網系統通常會隨著設備增加而持續修改。
因此，不建議把設備通訊、資料解析、資料庫、警示、報表及 API 全部寫死在同一段程式裡。
可以依照功能分成：
設備接收模組
↓
通訊協定解析模組
↓
資料格式轉換與檢查模組
↓
資料儲存模組
↓
警示／報表／AI 模組
↓
API／網頁／外部系統介面這樣做不代表一定要採用微服務，而是要避免其中一個設備或通訊方式變更時，整套系統都必須重寫。
例如：
- 更換某一廠牌電表，只修改該設備的解析模組
- 更換通知方式，不影響資料接收
- 增加新的報表，不修改原始通訊程式
- 更換資料庫時，盡量不影響上游設備介面
模組之間的資料格式與責任如果先定義清楚，後續會比較容易測試、替換及維護。
6. 確認資料庫由誰維護
開發工程師不只要決定資料如何寫入資料庫，也要先確認系統上線後由誰維護。
例如：
- 誰負責建立及修改資料表
- 誰負責資料庫版本更新
- 誰檢查硬碟容量
- 誰執行備份
- 誰確認備份資料能否還原
- 誰處理資料庫異常
- 歷史資料要保留多久
- 是否需要自動壓縮、彙整或刪除舊資料
資料要使用 MySQL、SQL Server、時間序列資料庫，還是 CSV 型態資料庫，除了考慮資料量與查詢方式，也要考慮維護人員的技術背景。
如果公司有專職 RD、DBA，或熟悉資料庫程式與查詢工具的人員，可以依照關聯查詢、權限、交易及效能需求選擇合適的資料庫。
但如果後續維護人員是廠務、MIS 或一般操作人員，不具備 SQL 或資料庫程式經驗，而且資料量與查詢需求也適合，CSV 型態資料庫會比較容易使用。只要資料有依設備、日期及統計週期整理，維護人員就能使用 Excel 或文字工具讀取，也比較容易備份、搬移及交接。
CSV 型態資料庫仍然要由程式定義資料夾層級、檔名、欄位、時間週期及讀寫規則。維護人員可以直接讀取，不代表可以任意修改系統保存的原始內容。如果系統需要大量並行寫入、複雜關聯查詢、交易一致性或集中式權限管理，就要再評估關聯式資料庫、時間序列資料庫或其他儲存方式。
如果廠務、行政或其他人員需要新增設備、修改名稱或查詢資料，應提供管理介面，而不是要求他們直接操作資料庫。
■結語
被公司要求評估或規劃物聯網伺服器時，不需要立刻決定要使用哪些通訊協定、資料庫、開發框架或部署平台。可以先用下面這張確認表，把已知、未知及負責人整理出來，再決定下一步要找誰討論。
物聯網伺服器規劃確認表
不需要在第一次會議就決定所有答案。先把已經確認與尚未確認的項目分開，至少能知道下一步還要找誰、補哪些資料。
下載可編輯版本（ZIP：Markdown＋可用 Excel 開啟的 CSV）
把填好的資料交給 AI 整理
確認表填完後，可以使用下面這段提示詞，讓 AI 協助整理目前已知的內容與還沒有被定義的部分。
你是一位物聯網伺服器系統規劃助手。
以下是我目前完成的物聯網伺服器規劃確認表。
請只根據我提供的內容整理，不要自行假設未提供的資訊，
也不要一開始就推薦品牌、雲端平台、程式框架或資料庫產品。
請協助我輸出：
1. 公司目的與需要實作的軟體功能
2. 從設備到使用端的完整資料路徑
3. 已確認與尚未確認的項目
4. 資料延遲、缺漏、重複、補傳及可信度風險
5. 現場、本地伺服器與遠端服務的責任分工
6. 接收、解析、儲存、警示、報表及 API 的模組責任
7. 資料儲存、備份、還原及後續維護責任
8. 下一次會議最優先需要確認的問題
請用表格輸出：
「項目／目前已知／尚未確認／可能風險／建議詢問對象」。
如果資料不足，請標示「待確認」，不要替我補答案。
以下是目前資料：
【貼上填寫後的確認表】確認表和 AI 可以協助整理問題，但不會直接替你決定系統該怎麼設計。
如果你還不清楚這些功能該怎麼設計
- 資料可信任度的設計
- 資料保留在本地端，同時支援遠端觀看的設計方式
- 各功能模組保持獨立的設計方式
G蛋有整理一門《物聯網伺服器，自己來就好》的課程，可以參考看看。