寫在完賽之後：三十天，一段從麵包板走向工廠產線的旅途

三十天前，這個專案可能只是工作桌上一塊裸露的樹莓派（Raspberry Pi）、幾條垂掛的 UART 杜邦線，以及幾份格式定義隨時在變動的生理訊號通訊協定草稿。

三十天後的今天，我們建立起的不僅僅是一套能抓取 BLE/UART 生理數據、即時轉換 CSV 的邊緣運算閘道器（Edge Computing Gateway），更是一套包含批次設備配置工具（RaspiConfigTool）、自動化佈署、系統服務防呆以及嚴謹版本控管體系的軟硬整合工程方案。

在硬體與邊緣端開發的世界裡有一句名言：「在工程師桌上能跑，不叫能用；能在產線組裝並於現場無人看管運作三個月不當機，才算及格。」

走到了這趟旅途的第 30 天，我想用這篇文章，把這個邊緣運算閘道器從「原型（PoC）」邁向「量產出貨（Production）」的踩坑血淚、工程原則以及未來開源演進的未竟之路，完整梳理並記錄下來。

一、 架構演進史：我們走過的四個里程碑

回顧這整套系統的演化，基本上正是現代 IoT / 邊緣運算裝置在產品化過程中的縮影：

[ Phase 1: 通訊協議驗證 ] 
   └── 杜邦線直連、UART / BLE 原始二進位封包解析、CSV 格式對齊 (16 欄位校正)
              ▼
[ Phase 2: 系統無人值守整合 ] 
   └── systemd 服務化守護、開機靜態 IP 配置 (set_static_ip.sh)、設定檔動態置換
              ▼
[ Phase 3: 現場網路容錯與免介入體驗 ] 
   └── wpa_supplicant 深度整合、nmcli 密碼預先注入（徹底根絕 Desktop 密碼彈窗）
              ▼
[ Phase 4: 產線規模化與工裝工具 ] 
   └── Paramiko 平行化 SSH 通訊、PyInstaller 獨立打包 (RaspiConfigTool.exe)、SOP 交付

1. 通訊協議與資料流水線（Pipeline）的落地

最底層的起點，是處理雜訊與封包校驗。面對生理訊號設備（心率、心率變異度 HRV、體溫、血氧等），資料掉包或欄位偏移都是致命傷。我們從 Protocol Parser 開始，逐 Byte 校驗 Checksum、拆解 Frame Size、處理浮點數編碼，並落實乾淨的 Dataclass 結構，最終將混亂的二進位封包馴服為規範嚴格的 16 欄位 CSV 輸出。

2. 脫離鍵盤螢幕：設備的自主生存能力

原型階段，我們習慣開著終端機看 stdout；但現場設備必須在「只插電源線」的狀態下獨立運作。
我們將資料擷取與網路配置全面移交給 systemd 守護行程，並透過 /etc/ctldevice.conf 與開機啟動腳本，確保閘道器在斷電重啟後，能在數十秒內重新校正 IP、自動掛載裝置並就定位。

3. 與 NetworkManager 的深度角力

在 Linux 系統（特別是兼具 Desktop GUI 的作業系統）中，Wi-Fi 切換看似簡單，實務上卻極為棘手。當我們動態切換 SSID（例如從 PHY 切至 PHYA）時，NetworkManager 常因缺少系統設定檔而跳出圖形化授權彈窗——這在沒有接螢幕滑鼠的邊緣閘道器上就是死局。
我們最後透過 nmcli 直接於系統底層動態建構 Connection Profile 並預填 WPA-PSK 金鑰，徹底斬斷了對人工介面操作的依賴。

4. 交付給產線的「工裝（Tooling）」思維

工程師不能永遠坐在產線旁邊幫每台機台打指令。
我們透過 Python Tkinter + Paramiko，將繁瑣的 SSH 連線、Excel 批次設備對照表、正規表示式替換與遠端服務重啟封裝成了 RaspiConfigTool，並透過 PyInstaller 打包為免裝環境的 Windows 獨立 .exe 與 SOP。這一步，標誌著專案真正從「研發代碼」變成了「產線可操作的交付物」。

二、 踩坑血淚提煉：邊緣運算裝置的三大鐵律

如果這三十天有什麼最值得傳承給下一位軟硬整合工程師的經驗，絕對是以下這三條在實體機台上用無數次除錯換來的原則：

鐵律一：單向維護原則（嚴禁在邊緣端直接還原代碼）

邊緣裝置（如 Raspberry Pi）多半透過部署腳本（SSH/SFTP）單向推送更新，這代表邊緣設備內部的 Git 歷史極可能是過時或未被追蹤的。

「實體機僅限觀測，修復一律回本機。」
嚴禁在邊緣機台上直接下達 git reset --hard 或 git checkout，這會直接摧毀先前上傳的所有熱修復或產線設定。任何代碼修正，必須在開發端完成後，單向推送覆蓋。

鐵律二：產線更新嚴格鎖定 Semantic Versioning Tag

在研發端，我們習慣 git pull 最新代碼快速驗證；但在出貨與產線部署上，這是大忌。

任何針對現場設備的更新，絕對禁止直接拉取開發分支最新代碼。
必須在確定穩定後：

1. 更新專案 VERSION.txt
2. 建立正式版標籤（如 git tag v1.0.0）並推送
3. 部署端一律使用明確標籤（git checkout v1.0.0）進行部署，杜絕「不小心把測試中的 Bug 燒進產線」的悲劇。

鐵律三：無人看守環境下的「防呆與重試」

任何遠端命令執行，都必須假設連線可能隨時斷開：

• 服務重啟前，腳本執行權限（chmod +x）先補上防呆。
• 發送 reboot 或重啟網路時，通訊層必須預期「連線中斷」是正常現象，設定短 Timeout 容錯機制，不能卡死在等待回應的阻塞狀態。

三、 開源這個閘道器：未竟之路與未來展望

完賽不是終點，而是開源專案生命週期的起點。回頭看這台邊緣運算閘道器，雖然已經具備穩定出貨的水準，但若要成長為一套通用、模組化的開放架構，還有幾條「未竟之路」正等待我們探索：

1. 安全的 OTA（Over-The-Air）空中升級架構

目前我們主要依賴區網內的 SSH/SFTP 進行批次配置更新。面對未來分散於全台或全球各場域的設備，一套支援端到端數位簽章、差分壓縮升級、弱網續傳的 OTA 系統是必經之路。

2. A/B 雙系統分區與防變磚（Anti-Brick）回滾機制

韌體或核心腳本升級最怕遇到斷電導致設備變磚。未來的架構需導入類似 RAUC 或 Mender 的 A/B 系統分區方案，配合硬體看門狗（Hardware Watchdog）；一旦升級後系統無法於時限內回報心跳，立即自動倒退回上一個健康的系統槽位。

3. 邊緣端輕量化即時推論（Edge AI / Signal Processing）

目前的閘道器主力在於資料採集、解碼與安全轉發。下一步，我們計畫將更多訊號特徵萃取（如即時心律變異 HRV 頻譜分析、血氧驟降預警算法）透過輕量化模型（如 TFLite / ONNX Runtime）直接在閘道器本地完成，做到**「本地毫秒級警報、雲端定期匯報趨勢」**的邊雲協同架構。

4. 插件化硬體抽象層（Hardware Abstraction Layer, HAL）

目前通訊邏輯與特定生理訊號設備緊密綁定。開源後的重要工作，是將 UART / BLE / Modbus 等傳輸協定抽象化為 Plugin 介面，讓社群開發者只需實作通訊介面的 read_frame() 與 parse_data()，就能無痛套用這套堅固的產線工具與守護架構。

四、 結語：讓程式碼在實體世界著陸

三十天的鐵人賽，我們從底層位元組的位移運算，寫到了 Windows 端的圖形化介面，再連繫到 Raspberry Pi 的 Linux 核心服務。

軟體工程師寫 Web 或後端服務時，世界是確定且乾淨的；但走入邊緣運算與硬體工程，世界是充滿雜訊與隨機性的——插拔的瞬間、不穩定的 Wi-Fi、產線人員不小心的誤觸、意外的中斷。

而工程師的浪漫與價值，就在於用嚴謹的架構與防呆機制，在混亂現實與物理世界之中，為系統建立起不可撼動的秩序。

感謝這三十天一路關注這個邊緣閘道器誕生的所有讀者與夥伴。開源的旅程才正要展開，我們 GitHub 專案見！

感謝大家！